method and apparatus for state/mode transition

专利摘要:
METHOD AND APPARATUS FOR MODE/STATE TRANSITION. A user equipment implements a method of processing indication messages, such as SCRI, release link indication signaling messages. For at least one RRC, the resource control state radio, if the current state of the RRC UE is a result of a previously sent indication, the UE inhibits from sending an additional indication message.
公开号:BR112012012362B1
申请号:R112012012362-9
申请日:2010-10-05
公开日:2021-05-18
发明作者:Johanna Lisa Dwyer；Paul Marcus Carpenter
申请人:Blackberry Limited；
IPC主号:

专利说明:

CROSS REFERENCE TO RELATED ORDERS
This application claims the benefit of U.S. Provisional Patent Application No. 61/263,823, filed November 23, 2005, which is hereby incorporated by reference in its entirety. FIELD OF EXHIBITION
The present disclosure relates to radio resource control between a user equipment (UE) or other wireless or mobile device and a wireless network, and in particular to a transition between states and modes of operation in a wireless network, such as, for example, a universal mobile telecommunication system (UMTS) network. BACKGROUND
A universal mobile telecommunication system (UMTS) is a broadband, packet-based system for the transmission of text, digitized voice, video and multimedia. It is highly compliant with the standard for the third generation and is generally based on broadband code division multiple access (W-CDMA).
In a UMTS network, a radio resource control (RRC) part of the protocol stack is responsible for assigning, configuring, and releasing radio resources between the UE and the UTRAN. This RRC protocol is described in 25 detail in the 3GPP TS 25.331 specification. Two basic modes the UE can be in are defined as "idle mode" and "UTRA RRC connected mode" (or simply "connected mode" as used here). UTRA stands for UMTS terrestrial radio access. In idle mode 30, the UE or other mobile device is required to request an RRC connection whenever it wants to send any user data or in response to a radio call, whenever the UTRAN or the radio service support node General Packet Service (GPRS) in service (SGSN) call it by radio to receive data from an external data network, such as a push server. The behaviors in , idle and connected are described in detail in the Third Generation Partnership Project (3GPP) specifications TS 25.304 and TS 25.331.
When in a UTRA RRC connected mode, the device can be in one of four states. These are: CELLJDCH: A dedicated channel is allocated to the UE in uplink and downlink in this state for data exchange. The UE shall take actions as outlined in 3GPP 15 25,331. CELL_FACH: No dedicated channel is allocated to user equipment in this state. Instead, common channels are used to exchange a small amount of bursty data. The UE shall perform actions as outlined 20 in 3GPP 25,331, which includes the cell selection process as defined in 3GPP TS 25,304. CELL_PCH: The UE uses a discontinuous reception (DRX) for monitoring broadcast messages and radio calls via a radio call indicator channel (PICH).
No uplink activity is possible. The UE shall perform actions as outlined in 3GPP 25.331, which includes the cell selection process as defined in 3GPP TS 25.3 04. The UE shall perform the CELL UPDATE procedure after a cell reselection. URA_PCH: The UE uses a discontinuous reception (DRX) for monitoring broadcast messages and radio calls through a radio call indicator channel (PICK). No uplink activity is possible. The UE must perform actions as outlined in 3GPP 25,331, which 5 includes the cell selection process as defined in 3GPP TS 25304. this state is similar to CELL_PCH, except that the URA UPDATE procedure is triggered only by reselecting the UTRAN register area (URA).
The transition from an idle mode to a connected mode and vice versa is controlled by the UTRAN. When an idle UE requests an RRC connection, the network decides whether to move the UE to the CELL_DCH or CELL_FACH state. When the UE is in RRC connected mode, again it is the network that decides when to release the RRC connection. The network may also move the UE from one RRC state to another, prior to releasing the connection or, in some cases, instead of releasing the connection. State transitions typically are triggered by activity or data inactivity between the UE 20 and the network. Since the network cannot know when the UE has completed data exchange for a given application, it typically maintains the RRC connection for some time, anticipating more data to/from the UE. This is typically done to reduce call set-up latency and subsequent radio resource set-up. The RRC connection release message can only be sent by UTRAN. This message releases the signal link connection and all radio resources between the UE and the UTRAN. Generally, the term "radio bearer" refers to radio resources allocated between the UE and the UTRAN.
And the term "radio access bearer" generally refers to radio resources allocated between the UE and, for example, an SGSN (serving GPRS service node). The present disclosure will at all times refer to the radio resource, and that term shall refer, as appropriate, to one or both of the radio bearer and/or the radio access bearer.
The problem with the above is that even if an application in the UE has completed its data transaction and is not expecting any further data exchange, it still expects the network to move it to the correct state. The network may not even be aware of the fact that the application on the UE has completed its data exchange. For example, an application in the UE can use its own recognition-based protocol to exchange data with its application server, which is accessed through a UMTS core network. Examples are applications that run over User Datagram Protocol / Internet Protocol (UDP/IP) implementing their own quarantine delivery. In such a case, the UE knows whether the application server has sent or received all the data packets or not, and is in a better position to determine whether any further data exchange is to take place and hence to decide when to terminate the connection. of RRC associated with packet service domain (PS) . Since the UTRAN controls when the connected state of RRC is changed to a different state or to an idle mode, and the UTRAN is not aware of the data delivery status between the UE and the external server, the UE can be forced to staying in a higher data rate state or mode than is required, possibly resulting in decreased battery life for the mobile station and also possibly resulting in wasted network resources due to the radio resources being unnecessarily kept busy and thus not available to another user.
A solution to the above is to have the UE send a signaling release indication to the UTRAN when the UE perceives that it has finished a data transaction. In line with section 8.1.14.3 of the 3GPP TS 25.331 specification, the UTRAN can release the signaling connection upon receipt of the signaling release indication from the UE, causing the UE to transition to an idle mode or some other RRC status. A problem with the above solution is that the UTRAN could become flooded with signaling release indication messages from the UE and other UEs. SUMMARY
According to an aspect of the present application, there is provided a method of processing indication messages in a user equipment, the method comprising: for at least one RRC state, if the current RRC state of the UE is the result of a previously sent indication message, the UE prohibits itself from sending an additional indication message.
According to another aspect of the present application, a user equipment configured to process indication messages is provided, the user equipment configured to: for at least one RRC state, if the current RRC state of the UE is the result of a previously sent referral message, prohibit yourself from sending an additional referral message. BRIEF DESCRIPTION OF THE DRAWINGS
The present exposition will be better understood with reference to the drawings, in which: Figure 1 is a block diagram showing RRC states and transitions; Figure 2 is a schematic of a UMTS network showing several UMTS cells and one URA; Figure 3 is a block diagram showing the various stages in an RRC connection establishment; Figure 4A is a block diagram of an example transition between a connected mode state of CELL_DCH and an idle mode initiated by the UTRAN according to the current method; Fig. 4B is a block diagram showing an example transition between a CELL_DCH state connected mode transition and an idle mode using signaling release indications; Figure 5A is a block diagram of an example transition between a CELL_DCH idle state and a CELL_FACH idle state to an UTRAN-initiated idle mode; Figure 5B is a block diagram of an example transition between the CELL_DCH idle state and an idle mode using signaling release indications; Figure 6 is a block diagram of a UMTS protocol stack; Figure 7 is an example UE that can be used in connection with the present method; Figure 8 is an example network for use in connection with the present method and system; Fig. 9 is a flowchart showing the steps of adding a cause to a signaling connection release indication in the UE; Figure 10 is a flowchart showing the steps followed by a UE upon receiving a signaling connection release indication having a cause; Figure 11 illustrates a graphical representation of an example logic and a physical channel allocation during an example operation of the network shown in Figure 8, in which multiple concurrent packet data communication service sessions are provided with the UE; Figure 12 illustrates a functional block diagram of UE and network elements providing a resource release function for individual packet data services radio resource release agent in line with an embodiment of the present disclosure; Figure 13 illustrates a message sequence diagram representing a signaling generated in line with the operation of an embodiment of the present disclosure whereby a radio resource allocation for a PDP context is released; Figure 14 illustrates a message sequence diagram, similar to that shown in Figure 13, also representative of a signaling generated in line with the operation of an embodiment of the present disclosure whereby a radio resource allocation is released; Figure 15 illustrates a process diagram representing the process of an embodiment of the present disclosure; Figure 16 illustrates a method flowchart illustrating the method of operation of an embodiment of the present disclosure; Figure 17 illustrates a method flowchart, also illustrating the method of operation of an embodiment of the present disclosure; Figure 18 illustrates a method flowchart of an embodiment in which transition decisions are made based on a radio resource profile in a network element; Figure 19 illustrates a simplified block diagram of a network element capable of being used with the method of Figure 18; Figure 20 illustrates a data flowchart for sending an indication message or transition request; and Fig. 21 illustrates a data flowchart for setting a prohibition timer value in a UE. DETAILED DESCRIPTION
The examples and modalities provided below describe various methods and systems for transitioning a user equipment (UE) or other mobile device between various states/modes of operation in a wireless network, such as, for example, a UMTS network . It is to be understood that other implementations on other types of networks are also possible. For example, the same teachings could also be applied to a code division multiple access (CDMA) network (e.g., 3GPP2 IS-2000), a Wideband CDMA (W-CDMA) network (e.g., 3GPP UMTS / high speed packet access (HSPA) ), an evolved UTRAN network (eg LTE), or, by way of generalization, to any network based on radio access technologies using network-controlled radio resources or that it does not maintain any knowledge of the status of device application-level data exchanges. The specific examples and implementations described below, although presented for simplicity in relation to UMTS networks, are also applicable to these other network environments. Also, the network element is sometimes described below as the UTRAN. However, if network types other than UMTS are used, the network element can be selected appropriately based on the network type. In addition, the network element can be the core network in a UMTS system or any other appropriate network system, where the network element is the entity that makes transition decisions.
In one particular example, the present system and method provides for the transition from a connected RRC mode to a more battery efficient or radio resource efficient state or mode, while providing decision-making capabilities in the network. In particular, the present method and apparatus provide for transition based on receipt of an indication from a UE indicating, implicitly or explicitly, that an RRC state or mode transition associated with a particular signaling connection with resource from radio to another state or mode must occur. As will be appreciated, a transition indication such as this or request could use an existing communication to current standards, for example, a SIGNALING CONNECTION RELEASE INDICATION message, or it could be a new message dedicated to changing the state of the UE, such as a "preferred RRC status request" or a "data transfer completed indication message". A data transfer completed indication message is a message which indicates the completion of a higher layer 10 data transfer. As used here, an indication could refer to any scenario and could incorporate a request.
The transition indication originated by the UE may be sent in some situations, when one or more applications 15 in the UE have completed a data exchange and/or when a determination is made that an exchange of any application(s) data is not expected. (s). The network element can then use the indication and any information provided therein, as well as other information related to the radio resource 20, such as a quality of service, access point name (APN), packet data protocol context. (PDP), history information, among others, defined here as a radio resource profile, to make a network-specific decision as to whether to transition the mobile device to another mode or state, or do nothing . The transition indication provided by the UE or mobile device can take various forms and can be sent under different conditions. In a first example, transition indication can be sent based on a composite status of all applications residing in the UE. II
Specifically, in a UMTS environment, if an application in the UE determines that it has finished exchanging data, it can send a "done" indication to a "connection manager" component of the UE software. The connection manager 5 in a modality can keep track of all existing applications (including those providing a service by one or multiple protocols), associated packet data protocol (PDP) contexts, packet switched radio resources (PS ) associated and 10 associated circuit switched (CS) radio resources. A PDP context is a logical association between a UE and a PDN (public data network) running through a UMTS core network. One or multiple applications (for example, an email application and a browser application) in the UE 15 can be associated with a primary PDP context and multiple applications can be linked to the secondary PDP contexts. The connection manager receives "done" indications from different applications in the UE that are simultaneously active. For example, a user may 20 receive an email from a push server while surfing the web. After the email application has sent an acknowledgment, it may indicate that it has completed its data transaction. The browser application may behave differently and instead make a predictive determination (eg, to use an inactivity timer) of when to send a "done" indication to the connection manager.
Based on a composite status of these active application indications, the UE software may decide to send a transition indication to indicate or request from the irrigation that a transition from one state or mode to another should take place. Alternatively, the UE software may instead wait, before sending the transition indication, and introduce a delay, to ensure that the application has truly finished exchanging data and did not require it to be held in a battery state or mode. or resource intensive radio. Delay can be dynamic based on traffic history and/or application profiles. Whenever the connection manager determines with some probability that no application is expected to exchange data, it can send a transition indication to the network to indicate that a transition should take place. In a specific example, the transition indication could be a request for a state transition in connected mode to the UTRAN.
As described in more detail below, based on receipt of a transition indication and, optionally, a radio resource profile, a network element, such as the UTRAN in a UMTS environment, may decide to transition from the UE to from one state or mode to another.
Other transition indications are possible. For example, rather than relying on a composite status of all active applications in the UE, the UE software can, in an alternative modality, send a transition indication every time a UE application has completed a data exchange and /or the application is not expected to exchange more data. In this case, the network element (e.g. the UTRAN), based on an optional radio resource profile for the UE as described with reference to Figure 18 below, can use the indication to make a transition decision.
In yet another example, the transition indication could simply indicate that one or more applications in the UE have completed a data exchange and/or that the UE application(s) is not expected to exchange any data to more. Based on this indication and an optional radio resource profile for the UE, the network (for example, the UTRAN) can decide whether to transition the UE to a more appropriate state or mode of operation.
In a further example, the transition statement could be implied rather than explicit. For example, the referral can be part of a status report sent out periodically. This status report could include information such as whether a radio link buffer has data, or it could include information about outgoing traffic.
When the UE sends a transition indication, it can include additional information in order to assist the network element in making the decision to act on the indication. This additional information would include the reason or cause for the UE to send the message. This cause or reason (explained in more detail below) would be based on the UE determining a need for a "quick sleep" type behavior. This additional information may be via a new information element or a new parameter in the indication message transition.
In an additional modality, a timer could exist in the UE to ensure that a transition indication cannot be sent until a duration of time has elapsed (ban duration) since a previous transition indication was sent. This prohibit timer restricts the UE from sending the transition indication message too often and further allows the network to make a determination depending on which messages are triggered only with a given maximum frequency. The length of time could be determined by a timer whose value is pre-configured, or regulated by a network (indicated or signaled). If the value were regulated by a network, it could be ported into new or existing messages, such as RRC Connection Request, RRC Connection Release, Radio Carrier Establishment, UTRAN Mobility Information or an Information Block of System, among others, and could be an element of information in those messages. The value could alternatively be carried in a ban transition indication portion of an RRC connection establishment message sent by the UTRAN in response to an RRC connection request message received from the UE, for example.
In an alternative embodiment, the value could be ported to the UE in a message whose type depends on a state of the UE. For example, the network could send the value to all UEs in a cell as a portion of a system information message, which is read by the UE when it is in an INACTIVE state of URA_PCH, Cell_PCH or CELL_FACH. In yet another embodiment, the value could be sent as a portion of an RRC connection establishment message.
Network-generated messages may also carry a prohibition timer value implied by not including a prohibition timer in the message or in an information element in the message. For example, upon determining that a prohibition timer is omitted from a received message, a UE applies a predetermined value for use as a prohibition timer value. An example use of prohibit timer value omission is to prohibit the UE from sending a transition indication message. In such a situation, when a UE detects the omission of an expected prohibition timer value in an received message, the UE may, based on the omission, be prohibited from sending any transition indication messages. One way to achieve this is for the UE to adopt an infinite prohibition timer value.
In another embodiment, when the UE detects the omission of a prohibition timer value (and, for example, endows an infinite prohibition timer value), it can send transition indications, but without including any additional information, specifically, it can omit the cause to trigger the sending of the transition indication (described further below in more detail). Omitting a cause element in a transition indication message can guarantee backwards compatibility by allowing UEs to use an existing transition indication message (eg, SIGNALING CONNECTION RELEASE INDICATION) to request or indicate a transition.
The non-inclusion of a ban timer in the received message is further detailed with reference to an example embodiment, where a System Information Block is broadcast in a cell, or sent to a UE, and the System Information Block is configured to carry a ban timer value. In this mode, if the UE receives a System Information Block that does not contain a prohibition timer, known as T3xx, in the message or in an information element in the message, in which case the UE may determine not to allow the UE to send the transition indication message, for example, by setting the prohibition timer, T3xx, to infinity.
The non-inclusion of a prohibition timer is further detailed with reference to another exemplary embodiment, in which a prohibition timer, T3xx, is omitted from an UTRAN Mobility Information message. In such a situation, a recipient UE may continue to apply a previously stored prohibit timer value. Alternatively, the UE, upon detecting the omission of the prohibition timer T3xx, can determine not to allow the UE to send the transition indication message, for example, by setting the prohibition timer T3xx to infinity.
In yet another exemplary embodiment, a UE, upon detecting the omission of a prohibition timer in the received message or in an information element in the message, sets the prohibition timer value to another preset value (e.g. one of 0 seconds, 5 seconds, 10 seconds, 15 seconds, 20 seconds, 30 seconds, 1 minute, 1 minute and 30 seconds, 2 minutes), Alternatively or additionally, these examples can apply to other messages generated on the network .
In other embodiments, if the prohibit timer value) is not sent or signaled to the UE in a message or an information element, or the prohibit timer is not read from broadcast system information or received from other Dedicated UTRAN messages in the transition from one cell to another, sending a transition indication may or may not occur.
Specifically, in one embodiment, the UE upon detecting that there is no prohibit timer present, does not initiate a transition indication based on a higher layer determining that there is no more PS data to transmit.
In an alternative embodiment, the UE, upon detecting that there is no prohibit timer present, may initiate a transition indication based on the higher layer determining that there is no more PS data to transmit.
In yet another embodiment, if no timer value is received from the UTRAN in a message, or an information element in a message (via broadcast or otherwise), instead of setting the timer value in the UE to infinite, the UE may set the prohibit timer to zero or alternatively clear any setting for the timer and instead be allowed to send a transition indication. In this case, the UE could omit or be prohibited from appending a cause in the transition indication message. In one modality, a RECOMMEND message
SIGNALING CONNECTION RELEASE is used as an example of a transition indication. In one embodiment, the transition indication is carried using the signaling connection release indication procedure, the signaling connection release indication procedure is used by the UE to indicate to the UTRAN that one of its signaling connections has been released.
Specifically, according to Section 8.1.14.2 of TS 25.331, the UE shall, upon receiving a request to release the signaling connection from the upper layers to a specific CN domain, check if the signaling connection in the variable "ESTABLISHED_SIGNALLING_CONNECTIONS " for the specific CN domain identified in the "CN domain identity" information element exists. If it exists, the UE can start the signaling connection release indication procedure.
In case the prohibit timer value is not signaled or otherwise ported to the UE, no signaling connection release indication cause is specified in the SIGNALING CONNECTION RELEASE INDICATION message. Those skilled in the art will appreciate that, in this alternative embodiment, the lack of a timer value does not result in a timer value being set to infinity.
On the UTRAN side, upon receipt of a SIGNALING CONNECTION RELEASE INDICATION message without a cause, the UTRAN indicates the release of the signaling connection for the identified CN domain identity to the higher layers. This can then initiate the release of the established radio resource control connection.
According to another alternative embodiment, when the UTRAN signals or carries a timer value for the UE, for example, the prohibition timer T3xx in the information element "Timers and UE constants in connected mode" (or using a system information, such as SIB1, SIB3 or SIB4, or with a dedicated UTRAN mobility information message), the release procedure takes place according to the following. First, the UE can check if there are any circuit switched domain connections indicated. These connections can be indicated in the variable "ESTABLISHED_SIGNALLING_CONNECTIONS". If there are no circuit-switched domain connections, a check could take place to determine if an upper layer indicates that there will be no packet-switched domain data for an extended period.
If there are no circuit switched domain connections and no packet switched domain data is expected for an extended period, the UE can then check whether the T3xx timer is running.
If timer T3xx is not running, the UE will set a "CN Domain Identity" information element to the packet switched (PS) domain. Further, the information element "Cause of Signaling Connection Release Indication" is set to "UE requested end of PS data session". The SIGNALING CONNECTION RELEASE INDICATION message is transmitted on the DCCH using AM RLC. Still, after transmission, the T3xx timer is started.
The above procedure ends in a successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message, as confirmed by the RLC in the above procedure. In this mode, the UE is prohibited from sending the SIGNALING CONNECTION RELEASE INDICATION message with a signaling connection release indication cause set to "UE requested end of PS data session", while timer T3xx is running or until the T3xx timer has expired.
When the T3xx timer is running, if the signaling connection release indication procedure is started due to no additional packet switched domain data for an extended duration, the UE will be responsible for implementing the possibility to start the procedure on expiration of the T3xx timer. The UE's decision may be based on the determination as to whether it has any subsequent signaling connection release request or indication messages to send, and if so, the UE's decision may include rechecking some or all of the same checks to initiate the procedure, as highlighted here.
On the UTRAN side, if the signaling connection release indication message received does not include a signaling connection release indication cause, the UTRAN may request the signaling connection release from a higher layer, and the upper layer may then start releasing the signaling connection. If, on the other hand, the received SIGNALING CONNECTION RELEASE INDICATION message includes a cause, the UTRAN may release the signaling connection or initiate a state transition to a more battery efficient state (eg, CELL_FACH, CELL_PCH, URA_PCH or SLEEP MODE).
The above ban duration can be based on the state the user would like to transition to. For example, the ban duration may be different if the mobile has indicated its last preference for some RRC states / modes versus others. For example, it could be different if the mobile had indicated a preference for idle mode, versus Cell_FACH or versus Cell_PCH/URA PCH states. In the case where the Inhibit Duration is regulated by the network, this can be obtained by the network indicating / sending two (or more) sets of values to the mobile, to be used depending on the scenario. Alternatively, the indication could be done in such a way that the appropriate prohibition duration value is only indicated / signaled to the mobile: for example, if the UE wants to transition to Cell_PCH, a different elapsed time duration could be regulated in addition to the UE wants to transition to Inactive.
The ban duration from above may be different depending on which state / RRC mode the mobile is currently in (eg Cell_DCH/Cell_FACH versus Cell_PCH/URA_PCH, or in Cell_DCH versus Cell_FACH, or Cell_PCH/URA_PCH).
The ban duration from above can be different depending on whether the network has already acted on the RRC status information preferably from the mobile. This recognition can take place on the network, or on the mobile side. In the first case, this can affect the prohibition values indicated / signaled by the network for the mobile. In this second case, different sets of inhibit duration values can be pre-configured or indicated / signaled by the network. As a particular case, the ban/functionality duration can be reduced or canceled if the network has acted on the RRC state information preferably from the mobile, for example, has initiated a state transition to an indicated state by the EU.
The ban duration from above may differ depending, for example, on preferences, resources, abilities, loads or capabilities of the network. A network can indicate a short ban duration if it is able to receive frequent transition indication messages. A network can indicate a long ban duration if it is unable or unwilling to receive frequent transition indication messages. A network can indicate a specific period of time during which a UE cannot send transition indication messages. The specific time period can be indicated numerically (ie 0 second, 30 seconds, 1 minute, 1 minute 30 seconds, 2 minutes or infinity), for example. A UE which receives a 0 second ban duration is able to send transition indications without delay. A UE which receives a prohibition duration of infinity is unable to send transition indications.
A maximum number of messages per time window (eg "no more than 15 messages every 10 minutes") can be used / specified, instead of or in addition to the ban duration. Combinations of ban durations/maximum messages per time window are possible.
By way of example, the present disclosure generally describes the receipt of an RRC CONNECT REQUEST message sent by an UTRAN from a UE. Upon receipt of an RRC CONNECTION REQUEST message, the UTRAN must, for example, accept the request and send an RRC CONNECTION ESTABLISHMENT message to the UE. The RRC CONNECTION ESTABLISH message may include a ban transition indication, which is known as the T3xx timer. Upon receipt of the RRC CONNECTION ESTABLISHMENT message sent by the UE, the UE must, for example, store the value of the T3xx timer, replacing any previously stored value, or, if the T3xx timer is not in the RRC CONNECTION ESTABLISHMENT message , set the timer value to infinity. In some embodiments, the RRC CONNECTION ESTABLISHMENT message should include a prohibition transition indication to ensure that the UE knows that the UTRAN supports the prohibition transition indication signaling.
In one embodiment, it is assumed that during a move in a DCH state, the UE will keep its currently stored value for the prohibit timer. In some cases where the prohibit timer is set to infinity, this may mean that the UE must wait for the network data inactivity timers to expire and the network moves the UE to an RRC state where it can receive or determine a new value for the ban timer. In other cases where the prohibit timer has some value other than infinity before the point-to-point transfer, this other value continues to be used, until the UE is able to update the timer value to the one indicated in the new cell .
In some cases, the ban timer and transition indication message (for example, SIGNALING CONNECTION RELEASE INDICATION) cannot be implemented in some networks or in some cells in a network. For mobility purposes, if there is no support available for the feature of sending a transition indication or request message (particularly in the case where a cause is used), the UE should by default not send the message. This avoids unnecessary transmissions and the associated waste of network resources and battery resources.
Furthermore, for mobility purposes, a different vendor network equipment used in a network can lead to 20 adjacent cells using different prohibit timers, which need to be updated in the UE when the UE moves between cells.
In an alternative embodiment, this is handled by providing that all point-to-point transfer and bearer control related messages include a value for a T3xx ban timer. These messages are referred to here as mobility messages. This allows the UE to receive new prohibit timer values when moving between cells.
It also allows the UE to set a default timer value for the prohibition timer if one of these mobility messages does not contain a prohibition timer value. As will be appreciated, if no prohibit timer value is received in the mobility messages, this will indicate that the cell is not enabled for fast sleep.
As another example of a transition indication procedure, a Data Transfer Complete Indication procedure can be used by the UE to indicate to the UTRAN that it has been determined that it does not need to transfer any more PS domain data. Regarding the example described above, the UE would not send the Data Transfer Complete Indication message before timer T3xx has expired, if timer T3xx were running.
The Data Transfer Complete Indication procedure begins with an indication that the RRC or higher layers will have no more PS domain data for an extended duration. If a CS domain connection is indicated in the ESTABLISHED_SIGNALLING_CONNECTIONS variable or if the T3xx timer is set to infinity, the procedure will terminate. Otherwise, if timer T3xx is not running (ie has expired) or is set to 0 second, a DATA TRANSFER COMPLETE INDICATION message will be submitted to the lower layers for transmission using AM RLC on DCCH, after which the T3xx timer is started or reset when the message has been delivered to the lower layers.
The UTRAN upon receiving the DATA TRANSFER COMPLETE INDICATION may decide to initiate a UE transition to a more battery efficient RRC state or an idle mode. The UE shall not send the Data Transfer Complete Indication message while the T3xx timer is running.
The present disclosure provides a method for controlling the use of a transition indication message by a user equipment, comprising including a prohibition transition indication in a configuration message; and sending the configuration message with the prohibition transition indication to the user equipment.
The present disclosure further provides a network element configured to control the use of a transition indication message by a user equipment, the network element configured to: include a prohibition transition indication in a configuration message; and sending the configuration message with the transition indication message to the user equipment.
The present disclosure further provides a method in a user equipment (UE) for sending a transition indication, the method comprising setting a timer in accordance with a prohibition transition indication received from a network element; detecting that a data transfer is complete; and sending the transition indication upon detection that the timer is not running.
The present disclosure further provides a user equipment configured to send a transition indication, the user equipment configured for: setting a timer in accordance with a prohibition transition indication received from a network element; detecting that a data transfer is complete; and sending the transition indication upon detection that the timer is not running.
Reference is now made to Figure 1. Figure 1 is a block diagram showing the various modes and states for the radio resource control portion of a protocol stack in a UMTS network. In particular, the RRC can be in an idle mode of RRC 110 or in a connected mode of RRC 120.
As will be appreciated by those skilled in the art, a UMTS network consists of two land-based network segments. These are the core network (CN) and the universal terrestrial radio access network (UTRAN) (as illustrated in figure 8). The core network is responsible for switching and routing data calls and data connections to the external networks, while the UTRAN handles all radio-related functionality.
In idle mode of RRC 110, the UE must request an RRC connection for the establishment of the radio resource whenever data needs to be exchanged between the UE and the network. This may be as a result of an application in the UE requesting a connection to send data, or as a result of the UE monitoring a radio call channel to indicate whether the UTRAN or SGSN has sent a radio call to the UE to receive data from from an external data network, such as a push server. In addition, the UE also requests an RRC connection whenever it needs to send Mobility Management signaling messages such as Location Area Update.
Once the UE has sent a request to the UTRAN to establish a radio connection, the UTRAN chooses a state for the RRC connection to be in. Specifically, the connected mode of RRC 120 includes four separate states. These are CELL_DCH state 122, CELL_FACH state 124, CELL_PCH state 126, and URAJPCH state 128.
From the idle mode of RRC 110, the UE autonomously transitions to state CELL_FACH 124, in which it does its initial data transfer, subsequent to which the network determines which connected state of RRC to use to continue data transfer. This may include the network moving the UE to the cell dedicated channel (CELL_DCH) state 122 or keeping the UE in the cell early access channel (CELL_FACH) state 124.
In state CELL_DCH 122, a dedicated channel is allocated to the UE for uplink and downlink for data exchange. This state, since it has a physical channel dedicated to the UE, typically requires the greatest battery power from the UE.
Alternatively, the UTRAN can keep the UE in a CELL_FACH 124 state. In a CELL_FACH state, no dedicated channel is allocated to the UE. Instead, common channels are used to send a signal on a small amount of bursty data. However, the UE still has to continuously monitor the FACE and therefore it consumes more battery power than in a CELL_PCH state, an URA_PCH state and in idle mode.
In the connected mode of RRC 120, the state of RRC can be changed at the discretion of the UTRAN. Specifically, if a data inactivity is detected for a specific amount of time or data, a throughput below a certain threshold will be detected, the UTRAN can move the RRC state from CELL_DCH 122 state to CELL-FACH 124 state , state CELL_PCH 126 or state URA_PCH 128. Similarly, if the payload is detected to be above a certain threshold, then the state of RRC can be moved from state CELL_FACH 124 to state CELL_DCH 122.
From the CELL_FACH 124 state, if a data inactivity is detected for a predetermined time in some networks, the UTRAN can move the RRC state from the CELL_FACH 124 state to a radio call channel (PCH) state. This can be state CELL_PCH 126 or state URA_PCH 128.
From the CELL_PCH 126 state or the URA_PCH 128 state, the UE must move to the CELL_FACH 124 state in order to initiate an update procedure to request a dedicated channel. This is the only state transition the UE controls.
The idle mode of RRC 110 and state CELL_PCH 126 and state URA_PCH 128 use a discontinuous receive cycle (DRX) to monitor broadcast messages and radio call a radio call indicator (PICK) channel. No uplink activity is possible.
The difference between state CELL_PCH 126 and state URA_PCH 128 is that state URA_PCH 128 only triggers an URA update procedure if the current UTRAN registration area (URA) of the UE is not among the list of URA identities present in the current cell. Specifically, reference is made to Figure 2. Figure 2 shows an illustration of several cells of UMTS 210, 212 and 214. All these cells require a cell procedure and update if reselected to a CELL_PCH state. However, in an UTRAN registration area, each will be in the same UTRAN registration area (URA) 320, and thus an URA update procedure is not triggered when moving between 210, 212 and 214, when in an URA_PCH mode.
As seen in Figure 2, other cells 218 are outside of URA 320, and may be part of a separate URA or not part of any URA.
As will be appreciated by those of skill in the art, from a battery life perspective, the idle state provides the lowest battery usage compared to the states above. Specifically, due to the fact that the UE is required to monitor the radio call channel only at intervals, the radio does not need to be continuously active, but will instead wake up periodically. The compromise for this is the latency for sending data. However, if this latency is not too great, the advantages of being in idle mode and saving battery power outweigh the disadvantages of connection latency.
Reference is again made to Figure 1. Several UMTS infrastructure vendors move between states 122, 124, 126, and 128, based on various criteria. These criteria could be the network operator's preferences with respect to the economy of signaling or the economy of radio resources, among others. The example infrastructures are outlined below,
In a first example infrastructure, the RRC moves between an idle mode and a Cell_DCH state directly after initiating access in a CELL_FACH state. In the Cell_DCH state, if two seconds of inactivity are detected, the RRC state changes to a CELL_FACH 124 state. If, in the CELL_FACH 124 state, ten seconds of inactivity are detected, then the RRC state will change to the CELL_PCH 126 state Forty-five minutes of inactivity in CELL_PCH 126 state will result in the RRC state moving back to 110 inactive mode.
In a second example infrastructure, an RRC transition may occur between an idle mode 110 and a connected mode 120, depending on a payload threshold. In the second infrastructure, if the payload is below a certain threshold, then the UTRAN will move the RRC state to the CELL_FACH 124 state. Conversely, if the data payload is above a certain payload threshold, then , the UTRAN will move the RRC state to a CELL_DCH 122 state. In the second infrastructure, if two minutes of inactivity are detected in the CELL_DCH 122 state, the UTRAN will move the RRC state to the CELL_FACH 25 124 state. state CELL_FACH 124, the UTRAN moves state from RRC to state CELL_PCH 126. In state CELL_PCH 126, two hours of inactivity are required before moving back to idle mode 110.
In a third example infrastructure, a move between idle mode 110 and connected mode 120 is always to state CELL_DCH 122. After five seconds of inactivity in state CELL_DCH 122, the UTRAN moves state from RRC to state CELL_FACH 124 Thirty seconds of inactivity in the CELL_FACH 124 state results in movement back to the 110 idle mode.
In a fourth example infrastructure, the RRC transitions from an idle mode to a directly connected mode to a .CELL_DCH 122 state. In the fourth example infrastructure, the CELL_DCH 122 state includes two settings. The first one includes a setting which has a high data rate and a second setting includes a lower data rate but still in the CELL_DCH state. In the fourth example infrastructure, the RRC transitions from idle mode 110 directly to the high data rate CELL_DCH substate. After 10 seconds of inactivity, the RRC state transitions to a low data rate CELL—DCH substate. Seventeen seconds of inactivity from the low data substate of state CELL_DCH 122 results in the RRC state changing it to idle mode 110.
The four example infrastructures above show how various UMTS infrastructure vendors are implementing states. As will be appreciated by those skilled in the art, in each case, if the time spent exchanging real data (such as an email) is significantly short compared to the time that is required to stay in the CELL_DCH state or the CELL_FACH state . This causes an unnecessary current drain, making the user experience on newer generation networks such as UMTS worse than on older generation networks such as GPRS.
Furthermore, although CELL_PCH 126 state is better than CELL_FACH 124 state from a battery life perspective, the DRX cycle in a CELL_PCH 126 state is typically set to a lower value than idle mode 110. As a result, the UE is required to wake up more often in CELL_PCH state 126 than in idle mode 110.
The URA_PCH 128 state with a DRX cycle similar to that of idle 110 is probably the optimal compromise between battery life and latency for connection. However, the URA_PCH 128 state is currently not implemented in UTRAN. In some cases, it is therefore desirable to quickly transition to idle mode as quickly as possible after an application has finished exchanging data, from a battery perspective.
Reference is now made to Figure 3. When transitioning from idle to connected mode, several signaling and data connections need to be made. Referring to Fig. 3, the first item to be performed is a connection establishment of RRC 310. As indicated above, this connection establishment of RRC 310 can be terminated only by the UTRAN. Once connection establishment of RRC 310 is performed, signaling connection establishment 312 is initiated.
Once signaling connection establishment 312 is completed, decryption and integrity establishment 314 is initiated. Upon completion of this, the establishment of 316 radio bearer is performed. At this point, data can be exchanged between the UE and UTRAN.
Disconnection is performed similarly in reverse order, in general. Radio bearer establishment 316 is overridden, and then connection establishment of RRC 310 is overridden. At this point, the RRC moves to idle 110 mode, as illustrated in figure 1.
Although the current 3GPP specification does not allow the UE to release the RRC connection or indicate its preference for the RRC state, the UE can still indicate the termination of a signaling connection to a specified core network domain, such as the packet-switched (PS) domain used by packet-switched applications.
According to section 8.1.14.1 of 3GPP TS 25.331, the SIGNALING CONNECTION RELEASE INDICATION procedure is used by the UE to indicate to the UTRAN that one of two signaling connections has been released. This procedure in turn can start the RRC connection release procedure.
Thus staying in the current 3GPP specifications, a signaling connection release can be initiated by disconnecting the signaling connection establishment 312. It is in the UE's ability to disconnect the signaling connection establishment 312, and this, in turn, according to specification, "may" initiate RRC connection release.
As will be appreciated by those skilled in the art, if the signaling connection establishment 312 30 is disconnected, the UTRAN will also need to clear the decryption and integrity establishment 314 and the radio bearer establishment 316, after the disconnected establishment. of signaling connection 312 have been
If the signaling connection establishment 312 is disconnected, the RRC connection establishment will typically be dropped by the network to the vendor's current infrastructures, if no CS connection is active.
Using this for one of the specific transition indication examples mentioned above, if the UE determines that the data exchange has ended, for example, if a "connection manager" component of the UE software is provided with an indication that the exchange of data data is complete, then the connection manager can determine whether to disconnect the 312 signaling establishment. For example, an email application on the device sends an indication that it has received an acknowledgment from the push email server that the 0 email was actually received by the push server. The connection manager, in one modality, can keep track of all existing applications, associated PDP contexts, associated PS radio resources, and associated circuit switched (CS) radio bearers. In other embodiments, a network element (e.g., the UTRAN) may keep track of existing applications, associated PDP contexts, QoS, associated PS radio resources, and associated CS radio bearers. A delay can be introduced at the UE or at a network element to ensure that the application(s) have truly finished exchanging data and no longer require an RRC connection, even after the "Ready" indication(s) have been sent. This delay can be made equivalent to an inactivity expiration associated with the application(s) or the UE. Each app can have its own inactivity expiration, so the delay can be a composite of all app expirations. For example, an email app might have a five-second inactivity expiration, while an active browser app might have a sixty-second expiration. A ban duration timer can still delay sending a transition indication. Based on a composite status of all these active application indications, as well as a radio resource profile and/or a ban duration timer delay in some modalities, the user software decides how long it can or should wait before of sending a transition indication (for example, by a signaling connection release indication or a state change request) to the appropriate core network (for example, PS domain). If the delay is implemented in the network element, the element will make a determination as to whether and how to transition the UE, but will only operate the transition after the delay has run its course. Inactivity expiration can be made dynamic, based on a traffic pattern history and/or an application profile.
If the network element transitions the UE to idle mode 110, which can happen at any stage of the connected mode of RRC 120, as illustrated in Figure 1, the network element will release the RRC connection and move the UE to mode idle 110 as illustrated in Fig. 1. This is also applicable when the UE is performing any packet data services during a voice call. In this case, the network can choose to release only one PS domain signaling connection, and keep the CS domain signaling connection, or alternatively, it can choose not to release anything and instead keep the signaling connections for both PS and CS 10 domains.
In an additional modality, a cause could be added to the transition indication indicating to the UTRAN the reason for the indication. In a preferred embodiment, the cause could be an indication that an abnormal state 15 caused the indication or that the indication was initiated by the UE as a result of a requested transition. Other normal (ie non-abnormal) transactions could also result in sending the transition indication.
In an additional preferred modality, several exhalations may cause a transition indication to be sent for an abnormal condition. The example timers below are not exhaustive, and other timers or abnormal conditions are possible. For example, TS 24.008 of 3GPP 10.2.47 specifies the 25 timer T3310 as:

TIMER T3310
This timer is used to indicate an attach failure. The failure to attach could be a result of the network or it could be a radio frequency (RF) issue, such as a collision or bad RF.
The attachment attempt could occur multiple times, and an attachment failure could result from a predetermined number of failures or an explicit rejection.
A second 3GPP 10.2.47 timer is the 10 T3300 timer, which is specified as:
TIMER T3330
This timer is used to indicate a routing area update failure. Upon expiration of the timer, an additional routing area update could be requested multiple times and a routing area update failure could result from a predetermined number of failures or an explicit rejection.
A third 3GPP 10.2.47 timer is the 5 T3400 timer, which is specified as:

TIMER T3340
This timer is used to indicate a failed GMM service request. Upon expiration of the timer, an additional GMM Service Request 5 could be requested multiple times and a GMM Service Request failure could result from a predetermined number of failures or an explicit rejection.
Thus, instead of a transition indication cause limited to an abnormal condition or a clearance by the UE, the transition indication cause could further include an information about which timer failed for an abnormal condition. In a specific example where a signaling connection release indication is used as a transition indication, the indication could be structured as:

INDICATION OF SIGNALING CONNECTION RELEASE
This message is used by the UE to indicate to the UTRAN a request to release an existing signaling connection. The addition of the signaling connection release indication cause allows the UTRAN or other network element to receive the signaling connection release indication cause, if it was due to an abnormal condition, and what was the abnormal condition. Based on the receipt of the SIGNALING CONNECTION RELEASE INDICATION, an RRC connection release procedure is in turn allowed to be started in the UTRAN.
In an implementation of this example, the UE, upon receipt of a request to release or abort a signaling connection from higher layers to a specific CN (core network) domain, initiates the connection release indication procedure. signaling, if a signaling connection is identified in a variable. For example, an ESTABLISHED_SIGNALLING_CONNECTIONS variable for the specific CN domain identified in the IE (information element) "CN domain identity" exists. If the variable does not identify any existing signaling connections, any ongoing establishment of a signaling connection for that specific CN domain will be aborted in another way. Upon initialization of signaling connection release indication procedures in Cell_PCH or URA_PCH states, the UE performs a cell update procedure using a cause "uplink data transmission". When a cell update procedure is successfully completed, the UE continues with the signaling connection release indication procedures that follow.
Specifically, the UE sets the information element (IE) "CN domain identity" to the value indicated by the higher logical layers. The IE value indicates the CN domain whose associated signaling connection the upper layers are marking to be released. If the CN domain identity is set to the PS domain, and if the upper layer indicates the cause for initiating this request, then the IE "SIGNAL RELEASE INDICATION CAUSE" will be set accordingly. The UE still removes the signaling connection with the identity indicated by the upper layers of the variable "ESTABLISHED_SIGNALLING_CONNECTIONS". The UE transmits a SIGNALING CONNECTION RELEASE INDICATION message, for example, on the dedicated control channel (DCCH) using an acknowledged mode radio link control (AM RLC). Upon confirmation of successful delivery of the release indication message by the RLC, the procedure ends.
An IE "Cause of signaling connection release indication" is also used in line with an embodiment of the present disclosure. The release cause is aligned, for example, with the existing 5 message definitions. The top tier release cause message is structured, for example, as:
correspond to the expiration of correspondingly numbered timers previously identified. A cause value is adjustable, in an implementation, as a "UE requested end of PS data session", rather than a "UE requested transition to idle" to remove the UE indication from a preference for a transition to idle and provide that the UTRAN decides on the state transition, although the expected result corresponds to that identified above by the cause value. The extension for signaling connection release indication is preferably, but not necessarily, a non-critical extension.
Reference is now made to Fig. 9. Fig. 9 is a flowchart of an example UE monitoring whether or not to send a signaling connection release indication to various domains (e.g. PS or CS). The process starts at step 910.
The UE transitions to step 912, in which it checks to see if an abnormal condition exists. Such an abnormal condition may include, for example, the T3310 timer, the T3320 timer, or the T3340 timer expiring, as described above. If these timers expire a certain predetermined number of times, or if an explicit rejection is received based on the expiration of any one of these timers, the UE will proceed to step 914, in which it sends a signaling connection release indication. The SIGNALING CONNECTION RELEASE INDICATION message is appended with a signaling release indication cause field. The signaling release indication cause field includes at least that the signaling connection release indication is based on an abnormal condition or state, and a modality includes the specific timer that expired to result in the abnormal condition.
Conversely, in step 912, if the UE finds that no abnormal conditions exist, the UE will proceed to step 920, in which it checks whether other data is expected in the UE. This may include, as described above, when an email is sent and a confirmation of the sending of the email is received back at the UE. Other examples of where the UE will determine that no further data is expected would be known to those skilled in the art.
In step 920, if the UE determines that data transfer is complete (or in the case of a circuit switched domain that a call is terminated), the UE proceeds to step 922, in which it sends a connection release indication of signaling in which the signaling release indication cause field has been added, and includes the fact that the UE requested a transition to idle or simply indicate an end to the PS session.
From step 920, if the data has not ended, the UE loops back and continues to check if there is an abnormal condition at step 912 and if the data has ended at step 920.
Once the signaling connection release indication is sent in step 914 or step 922, the process proceeds to step 930 and ends.
The UE includes functional elements, implementable, for example, by applications or algorithms performed through an operation of a UE microprocessor or by a hardware implementation, which form a checker and an emitter of transition indication. The checker is configured to check whether a transition indication should be sent. And a transition indication sender is configured to send a transition indication in response to an indication by the verifier that the transition indication should be sent. The transition indication may include a transition indication cause field.
In one implementation, the network is instead timer, and the UE need not send a cause value indicating the expiration of the timer. That is, the timer starts a synchronization upon network authorization. Cause codes are defined, and cause codes are provided by the network to the UE. These cause codes are used by the UE for timer initiation. The network is implicitly aware of the reason for a subsequent timer expiration as the cause code previously sent by the network causes the timer to start syncing. As a result, the UE does not need to send a cause value indicating the expiration of the timer.
As suggested by Figure 9, as well as the preceding description, a cause can be included and sent along with a transition indication (for example, a SIGNALING CONNECTION RELEASE INDICATION to indicate: 1.) an abnormal condition as well as 2.) a normal condition (not an abnormal condition, such as a request for a PS data session end and/or a transition to an idle mode)) . In various implementations, therefore, operations in the UE for adding the cause to the transition indication to indicate an abnormal condition or, alternatively, to indicate a preference for a request for a transition to idle or an end-of-session data from PS, this is normal operation. This operation, of course, also includes a UE operation in which a cause is added to the transition indication only when an indication of an abnormal condition is to be made. And conversely, this operation also includes a UE operation in which a cause is added to a transition indication just to indicate normal operations, that is, non-abnormal and transactions. That is, with respect to figure 9, in this alternative operation, if, in step 912, an abnormal condition exists, the branch yes will be taken to step 914, whereas, if an abnormal condition does not exist, then the UE will proceed directly to the end step 930. Conversely, in the other alternative operation like this, subsequent to the start step 912, a path is taken directly to the finished data step 920. If the data has ended, the yes branch will be taken to step 920 and thereafter to step 930. If the data has not ended in step 920, the branch will not be taken back to the same step, i.e. step 920.
Referring to Figure 10, when a network element receives the transition indication in step 1010 (e.g. a signaling connection release indication as shown), the network element examines the transition indication cause field, case present in step 1014, and in step 1016 it checks whether the cause is an abnormal condition or whether it is due to the UE requesting a transition to idle and/or a PS data session end. In step 1016, if the signaling connection release indication is in an abnormal condition, the network node will proceed to step 1020, in which an alarm may be noted for performing alarm monitoring and monitoring purposes. The key execution indicator can be updated accordingly.
Conversely, in step 1016, if the cause of the transition indication (e.g., a signaling connection release indication) is not the result of an abnormal condition, or, in other words, is the result of the UE requesting an end PS data session or a transition to inactivity, the network node will proceed to step 1030, in which no alarm is activated and the indication can be filtered from the performance statistics, thereby avoiding the performance statistics are distorted. From step 1020 or step 1030, the network node proceeds to step 1040, at which the process ends.
Reception and examination of the transition indication may result in initiation by the network element of a packet switched data connection termination or, alternatively, to a transition to another more suitable state, for example, CELL_FACH, CELL_PCH, URA_PCH or IDLE_MODE.
As suggested above, in some implementations, the absence of a cause in a transition indication can also be used to determine whether the transition indication is the result of a normal or abnormal condition and whether an alarm should be created. For example, if a cause is added just to denote normal conditions (ie, non-abnormal, such as, for example, a request for a PS data logout and/or a transition to idle mode), then the network element receives a transition indication without added cause, the network element may infer from the absence of a cause that the transition indication is the result of an abnormal condition and optionally create an alarm. Conversely, in another example, if a cause is added only to denote abnormal conditions, and the network element receives an uncaused transition indication, the network element may infer from the absence of a cause that the transition indication is the result of a normal condition (eg request to end PS data session and/or transition to idle mode) and not create an alarm.
As will be appreciated by those skilled in the art, step 1020 can be used to further distinguish between various alarm conditions. For example, an expiration of T3310 could be used to maintain a first set of statistics and an expiration of T3330 could be used to maintain a second set of statistics. Step 1020 can distinguish between the causes of the abnormal condition, thereby allowing the network operator to track performance more efficiently.
The network includes functional elements, implementable, for example, by applications or algorithms executed through the operation of a processor or by a hardware implementation, which form an examiner and an alarm generator. The examiner is configured to examine a transition indication cause field from the transition indication. The examiner checks whether the transition indication cause field indicates an abnormal condition. The alarm generator is configured to selectively generate an alarm if examination by the examiner determines that the signaling connection release indication cause field indicates the abnormal condition.
In one implementation, upon receipt of a signaling connection release indication, the UTRAN forwards the cause that is received and requests, from higher layers, the release of the signaling connection. The upper layers are then able to initiate the release of the signaling connection. The IE signaling release indication cause indicates the UE upper layer cause to trigger the RRC of the UE to send the message. The cause is possibly the result of an abnormal upper layer procedure. A differentiation of the cause of the message is ensured through successful IE reception.
One possible scenario includes a scenario in which, prior to confirmation by RLC of a successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message, a re-establishment of the transmit side of the RLC entity on the signaling radio bearer RB2 takes place. In case of such an occurrence, the UE retransmits the SIGNALING CONNECTION RELEASE INDICATION message, for example, on the uplink DCCH, using AM RLC on the signaling radio bearer RB2. In the case where a point-to-point inter-RAT (Radio Access Technology) transfer procedure from the UTRAN occurs prior to an acknowledgment by the RLC of the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message or the request , the UE aborts the signaling connection when in the new RAT.
In a further embodiment, instead of a "signaling connection release indication" or request, a "data transfer completed indication" could be used. A functionality similar to that described in figures 9 and 10 above would apply to this indication of data transfer completed.
In one embodiment, the data transfer completed indication is used by the UE to inform the UTRAN that the UE has determined that there is no CS domain data transfer in progress, and has completed its PS data transfer. Such a message is sent from the UE to the UTRAN on the DCCH using AM RLC, 10 for example. An example message is shown below. 10.2.x DATA TRANSFER COMPLETE INDICATION
This message is used by the UE to inform the UTRAN that the UE has determined that there is no CS domain data transfer in progress, that it has completed its PS data transfer. RLC-SAP: AM Logical Channel: DCCH Direction: UE—>UTRAN
Data Transfer Indication Completed
Reference is now made to Figure 20. The figure illustrates the embodiment in which a transition or request indication (for example, from a signaling connection release indication or a data transfer completed indication) is sent from the UE to the UTRAN. The process starts at step 2010 and proceeds to step 2012, in which a check is done at the UE to determine whether conditions at the UE are appropriate for sending a transition indication message. These conditions are described in the present disclosure, for example, with reference to Figure 11 below, and could include one or more applications in the UE determining that they have terminated a data exchange. These conditions can also include waiting for some length of time for the T3xx timer to expire, if it is running.
In an additional and alternative modality, conditions may include preventing the transition indication from being sent if the T3xx timer is set to infinity. As will be appreciated, the T3xx could include several discrete values, one of which represents an infinite value.
In step 2012, if the conditions are not appropriate for sending the transition indication or request message, the process will loop itself and continue to monitor until the conditions are appropriate for sending the transition indication or the request message. request.
Once the conditions are appropriate, the process proceeds to step 2020, in which a transition indication is sent to the UTRAN. Example indications are shown in the tables above.
The process then proceeds to step 2022, in which a check is made to determine whether the transition indication was successful. As would be appreciated by those skilled in the art, this could mean that the UTRAN has successfully received the transition indication and initiated a state transition. If so, the process proceeds to step 2030 and ends.
Conversely, if it is determined in step 2022 that the transition indication was not successful, the process proceeds to step 2024, and waits for a period of time. This wait could be implemented using an "inhibit duration", eg T3xx, which would not allow the mobile to send another transition indication message before a given duration has elapsed. Alternatively, the process could limit the number of transition indication messages in a given period of time (for example, no more than 15 messages in 10 minutes). A combination of ban duration and limiting the number of messages in a given period of time is also possible.
The duration could be predetermined, such as a value defined in the standards, it could be regulated by a network element, for example, as part of an RRC connection request, an RRC connection establishment message, an RRC connection release RRC, a radio bearer establishment, a system information broadcast message, a system information block battery, a SET UPDATE ACTIVE, a CELL UPDATE CONFIRMATION, a point-to-point transfer message for UTRAN , a physical channel reset message, a radio bearer reset message, a radio bearer release message, a transport channel reset message, or any request, setup, or reset message. Also, the duration could be regulated based on a parameter in the transition indication message. Thus, the duration could be longer if the UE were requesting a transition to Cell_PCH, instead of to Idle.
Signaling or sending the duration by a network element could take the form of an information element. As used here, a signaling or a dispatch could directly include the sending of information to a UE, or the dissemination of the information. Similarly, receipt at the UE could include a direct reception or a read of a broadcast channel. An example piece of information includes:
Transition Prohibition Indication O The T3xx values in a modality are defined as:

Definition of T3xx
In one modality, T3xx can be included in the existing UMTS information element "Timers and UE Constants in Connected Mode". This can therefore be broadcast in a cell by inclusion in the Type 1 System Information Block. In an alternative embodiment, the timer value could also be signaled using other system information messages such as SIB3 or SIB4 , or , alternatively or additionally, could be signaled with a dedicated UTRAN mobility information message.
As indicated in the Table above, the value of T3xx can vary between set values and include a zero value or an infinite value. The value zero is used to indicate that no ban needs to take place. The infinite value indicates that a transition indication message should never be sent.
In a mobility mode, the UE resets the value of T3xx whenever it transitions to a new network or cell. In this example, the value is set to infinity. This ensures that if a transition message or radio bearer messages does not contain a prohibit timer value, then, by default, the UE does not have to send the transition indication message. Thus, for example, if the transition or radio bearer messages do not contain a "prohibit transition indication", the timer value will be set to infinity and otherwise the timer value received in the indication overrides any previously valued stored.
In another alternative embodiment, the values of T3xx are defined as follows. The inclusion of the T3xx timer is optional, thus ensuring that, if not included, the UE does not have to support the configuration or use of this timer:

Receipt of the prohibit timer in a cell thus is an indication to the UE that the cell recognizes the use of the transition indication message. The UE may determine, if initiated by the RRC or higher layers, due to a determination of no more PS domain data for an extended duration, to signal a transition indication using a cause value. When the network receives a transition indication message (in whatever form, as captured in this document), with this cause value it can signal to the UE a transition from state transition to a more efficient RRC state in battery terms.
Whereas in an alternative embodiment, when the prohibit timer is not received or read in a cell, the UE can determine that the cause for sending the transition indication message is not supported by the UTRAN. In this case, the UE can determine not to set a value for T3xx and also not to use T3xx in relation to sending or prohibiting sending the transition indication message.
If the UE determines that the prohibit timer is omitted, then it can omit the inclusion of the cause value from the transition indication message and just send the transition indication message, based on a higher layer determination than it. you have no more PS data to transmit.
In an alternative embodiment, the UE determining that the prohibit timer is omitted, the UE shall not initiate a transition indication based on a higher layer determining that it has no more PS data to transmit.
In one embodiment of this described behavior, the transition indication message is the SIGNALING CONNECTION RELEASE INDICATION message.
In a first alternative embodiment, receipt of the prohibit timer in a cell thus is an indication that the cell recognizes the use of the transition indication messages. When sending this message is allowed when the T3xx is not set to an infinite value, then when the network receives a transition indication, it can determine that it is to signal to the UE a state transition to a more efficient RRC state in terms of battery (for example, CELL_FACH, CELL_PCH, URA_PCH or IDLE_MODE).
In a particular example using the 3GPP TSG-RAN2 25.331 standard, the following is added to the sections identified below.
Transition Prohibition Statement This is added to sections: 10.2.48.8.6 Type 3 System Information Block; 10.2.48.8.7 Type 4 System Information Block; 10.2.1 Active Regulation Update; 10.2.8 Update Cell Update Confirmation; 10.2.16a Point-to-point Transfer Command for UTRAN; 10.2.22 Physical Channel Reconfiguration; 10.2.27 Radio Carrier Reconfiguration; 10.2.30 Radio Carrier Release; 10.2.33 Establishment of Radio Carrier; 10.2.40 Establishment of RRC Connection; 10.2.50 Transport Channel Reconfiguration.
The messages described above, in addition to messages 10.2.48.8.6 Type 3 System Information Block and 10.2.48.8.7 Type 4 System Information Block are all examples of mobility information messages.
The above covers connections and system operations, as well as transitions between multiple cells, ensuring that a UE has a prohibit timer value, if that cell supports the transition indication message. For example, the point-to-point transfer command for UTRAN ensures that a transition from another radio access technology, such as a second-generation network to a third-generation network, provides a ban timer value, if supported. by the third generation network target cell.
In particular with reference to Fig. 21, a transition between cells occurred as a pre-condition or during another operation of the UE, as shown by reference numeral 2110 as 'Start'. The process proceeds to block 2112, at which a configuration message is received. This can be any of the messages identified above, and includes mobility and non-mobility messages. The process then proceeds to block 2114, at which a check is made to see if the setup message includes a prohibit timer value.
If not, the process proceeds to block 2120, where the prohibit timer value is set to infinity. Conversely, from block 2114, the process proceeds to block 2130 if it is determined that the setup message actually includes the prohibit timer value. In block 2130, the prohibit timer value is stored in the UE, replacing the previous value for the prohibit timer. The process then proceeds to block 2140 and ends. As will be appreciated, in one embodiment, the process of Fig. 21 is invoked whenever a network or cell change occurs, or whenever a transition indication needs to be sent.
Once the process has waited a predetermined time in step 2024, the process proceeds back to step 2012 to determine if the conditions for sending a transition indication still exist. If so, the process loops back to steps 2020 and 2022.
Based on the above, the prohibit timer value can be provided in various arrangements. In a first embodiment, it can be provided only by using an RRC connection establishment message to carry a prohibit timer value. In a second embodiment, the system information can be used to carry the prohibit timer value.
In a third modality, the RRC connection establishment and system information messages can both be used for sending the prohibit timer value to ensure that UEs in idle mode and in Cell_PCH / Cell_FACH and DCH states have the last information.
In a fourth modality, the prohibit timer value can be sent as in the third modality, with the addition of sending a prohibit timer value in a radio bearer establishment, so that when a PDP context is established not having a radio bearer, when a radio bearer is subsequently established for sending a data message, the prohibit timer value can be ported at that time.
In a fifth modality, the fourth modality can be combined with all mobility related messages as described above and including a reset, a cell update confirmation and a point-to-point transfer command to UTRAN to carry the timer value of prohibition.
From first to fourth modes, during mobility, the UE keeps its currently stored ban timer value. As indicated above, in some cases where the prohibit timer is set to infinity, this can mean that the UE must wait for the network timers to expire and that the network moves the UE to an RRC state where it can receive or determine a new value for the ban timer. In other cases where the prohibit timer has some value other than infinity before the point-to-point transfer, this other value continues to be used until the UE is able to update the timer value to the one indicated in the new cell.
For the fifth embodiment, the process of Fig. 21 is used to ensure that the prohibit timer value is updated during mobility, and that transition indication messages are not needlessly sent from a UE.
An exception can occur on RLC reset or on an inter-RAT change. If a reset of the transmit side of the RLC entity occurs before successful delivery of the transition indication message has been acknowledged by the RLC, in one embodiment, the UE retransmits the transition indication message on the uplink DCCH using AM RLC .
In one embodiment, if a UTRAN inter-RAT point-to-point transfer procedure occurs before the successful delivery of the transition indication message has been acknowledged by the RLC, the UE will abort the signaling connection while in the new RAT. On the network side, the process is handled similarly to that described with reference to figure 18 below.
Referring again to Fig. 1, in some cases it may be more desirable to be in connected mode 120 in a state such as URA_PCH 128 state than in idle mode 110. For example, if the latency for connection is required for the CELL_DCH state 122 or CELL_FACH 124 state in connected mode 120 is lower, it will be preferable to be in a PCH state of connected mode 120. There are various embodiments of this, such as, for example, by standards amendments to allow the UE request that the UTRAN move it to a specific state (for example, in this case, the state URA_PCH 128) .
Alternatively, the connection manager can take into account other factors, such as what state the RRC connection is currently in. For example, if the RRC connection is in the URA_PCH state, it might decide that it is unnecessary to move to idle mode 110 and thus no signaling connection release procedure is started.
In another alternative, the network element (for example, the UTRAN) may itself take into account other factors, such as what state the RRC connection is currently in and, for example, whether the RRC connection is in the URA_PCH state , may decide it is unnecessary to move to idle mode 110 and instead simply transition the UE to a more suitable state, rather than releasing the connection.
Reference is made to Figure 4. Figure 4A shows a current implementation of UMTS according to the infrastructure in example "four" above. As illustrated in Figure 4, time is across the horizontal axis.
The UE starts in idle mode of RRC 110 and, based on local or mobile generated data needing to be transmitted or a radio call received from the UTRAN, starts establishing an RRC connection.
As illustrated in Fig. 4A, connection establishment of RRC 310 occurs first, and the state of RRC is in a connection state 410 during this time.
Thereafter, signaling connection establishment 312, decryption and integrity establishment 314, and radio bearer establishment 316 occur. The RRC state is the CELL_DCH 122 state during these procedures. As illustrated in Figure 4A, the elapsed time to move from RRC idle to the time the radio bearer is established is approximately two seconds in this example. Data is then exchanged. In the example of Figure 4A, this is achieved in two to four seconds and is illustrated by step 420.
After the data is exchanged in step 420, no data is being exchanged except for the intermittent RLC signaling PDU as required and thus the radio resource is reconfigured by the network to move to a data rate DCH configuration lowest after 5 approximately ten seconds. This is illustrated in steps 422 and 424.
In the lowest data rate DCH setting, nothing is received for seventeen seconds, at which point the RRC connection is released by the network in step 428.
Once the RRC connection release is initiated in step 428, the RRC state proceeds to a 430 disconnect state for approximately forty milliseconds, after which the UE is in RRC 110 idle mode.
Also illustrated in Fig. 4A, the current consumption of the UE is illustrated for the period in which the RRC is in the CELLJDCH 122 state. As seen, the current consumption is approximately 200 to 300 milliamps for the entire duration of the CELL_DCH state. During a disconnect and 20 inactivity, around 3 milliamps are used, assuming a 1.28 second DRX cycle. However, the 35-second current draw at 200 to 300 milliamps is draining the battery.
Reference is now made to Figure 4B. Figure 25 4B uses the same infrastructure as example "four" above, only now implementing signaling connection release.
As illustrated in Fig. 4B, the same setting steps 310, 412, 314 and 316 occur, and this takes the same amount of time when moving between idle mode of RRC 110 and CELL_DCH state of RRC 122.
Furthermore, the exchange of PDU of data from RRC to the example email in step 420 of Fig. 4A is also done in Fig. 4B, and this takes approximately two to four seconds.
The UE in the example of Figure 4B has an application-specific inactivity expiration, which in the example of Figure 4B is two seconds and is illustrated by step 440. After the connection manager has determined that there is inactivity for the specific amount of time , the UE sends a transition indication, which in this case is a signaling connection release indication in step 422, and in step 448, the network proceeds, based on receipt of the indication and a resource profile of radio to the UE to release the RRC connection.
As illustrated in Figure 4B, the current consumption during the CELL_DCH 122 step is still around 200 to 300 milliamps. However, the connection time is only around eight seconds. As will be appreciated by those skilled in the art, the considerably shorter amount of time the mobile spends in the CELLJDCH 122 state results in significant battery savings for the UE device.
Reference is now made to Figure 5. Figure 5 shows a second example using the infrastructure indicated above as Infrastructure "three". As with Figures 4A and 4B, a connection establishment takes place, which takes approximately two seconds. This requires establishing connection of RRC 310, display tube 2 312, establishment of decryption and integrity 314, and establishment of radio bearer 316.
During this establishment, the UE moves from the idle mode of RRC 110 to a state CELL_DCH 122 with an RRC state connection step 410 between them.
As with Fig. 4A, in Fig. 5A, an RLC data PDU exchange takes place in step 420, and, in the example of Fig. 5A, it takes two to four seconds.
According to infrastructure three, an RLC signaling PDU exchange does not receive data, and thus is idle for a period of five seconds in step 422, except for the intermittent RLC signaling PDU, as required, at which point the radio resource reconfigures the UE to move to a CELL_FACH 124 state from the CELL_DCH 122 state. This is done in step 450.
In state CELL_FACH 124, the RLC reset PDU exchange discovers that there is no data, except for the intermittent RLC signaling PDU, as required for a predetermined amount of time, in this case thirty seconds, at which point a connection release RRC over the network is performed in step 428. As seen in Figure 5A, this moves the RRC state to idle mode 110.
As seen further in Figure 5A, the current draw during DCH mode is between 200 and 300 milliamps. When moving to the CELL_FACH 124 state, the current draw drops to approximately 120 to 180 milliamps. After the RRC connector is released and the RRC moves to 110 idle mode, the power consumption is approximately 3 milliamps.
The UTRA RRC connected mode state being the CELL_DCH 122 state or the CELL_FACH 124 state lasts for approximately forty seconds in the example of Figure 5A.
Reference is now made to Figure 5B. Figure 5B illustrates the same infrastructure "three" as Figure 5A, with the same connection time of around two seconds 5 for obtaining the connection establishment of RRC 310, the signaling connection establishment 312, the establishment of decryption and integrity 314 and the establishment of radio bearer 316. In addition, the exchange of data PDU of RLC 420 takes approximately two to 10 four seconds.
As with Fig. 4B, a UE application detects a specific inactivity expiration in step 440, at which point the transition indication (e.g., a signaling connection release indication 442) is sent by the UE and as a Consequently, the network releases the RRC connection in step 448.
As can be seen further in Fig. 5B, the RRC starts in idle mode 110, moves to state CELL-DCH 122, without proceeding to state CELL_FACH.
As will be seen further in Figure 5B, the current consumption is approximately 200 to 300 milliamps when the RRC stage is in the CELL_DCH 122 state, which, according to the example in Figure 5, is approximately eight seconds .
Therefore, a comparison between Figures 4A and 4B and between Figures 5A and 5B shows that a significant amount of current consumption is eliminated, thereby extending the battery life of the UE. As will be appreciated by those skilled in the art, the above 30 can still be used in the context of current 3GPP specifications. Reference is now made to Figure 6. Figure 6 illustrates a protocol stack for a UMTS network.
As seen in Figure 6, UMTS includes a CS 610 control plane, a PS 611 control plane, and a PS 630 user plane. a portion of access stratum 616 exist.
The NAS portion 614 in the CS 610 control plane includes a call control (CC) 618, supplemental services (SS) 620 and a short message service (SMS) 622 .
The NAS 614 portion of the PS 611 control plane includes a mobility management (MM) and a mobility management of GPRS (GMM) 626. It further includes session management / radio access bearer management SM / RABM 624 and GSMS 628. The CC 618 provides call management signaling for circuit switched services. The session management portion of SM / RABM 624 provides a PDP context activation, deactivation and modification. SM / RABM 624 also provides quality of service negotiation.
The main function of the RABM portion of the SM / RABM 624 is to connect a PDP context to a radio access bearer. Thus, SM / RABM 624 is responsible for establishing, modifying and releasing radio resources.
The CS 610 control plane and the PS 30 control plane 611 in access layer 616 rest on radio resource control (RRC) 617.
The NAS 614 portion in the PS 630 user plane includes an application layer 628, a TCP/UDP layer 636, and a PDP layer 634. The PDP layer 634 can include, for example, an Internet protocol (IP).
Access layer 616, in the PS 630 user plane, includes a packet data convergence protocol (PDCP) 632. The PDCH 632 is designed to make the WCDMA protocol suitable for realizing a TCP 10 / protocol IP between UE and RNC (as seen in Fig. 8), and is optionally for IP traffic stream protocol header compression and decompression.
The UMTS radio link control (RLC) layer 640 and the medium access control (MAC) layer 650 form 15 radio link sublayers of the UMTS radio interface and reside in the RNC node and user equipment.
The UMTS layer 1 (LL) layer (physical layer 660) is below the RLC/MAC layers 640 and 650. This layer is the physical layer for communications.
While the above can be implemented on a variety of mobile or wireless devices, an example of a mobile device is outlined below with respect to Figure 7. A reference is now made to Figure 7.
The UE 700 is preferably a two-way wireless communication device that has at least voice and data communication capabilities. The UE 700 preferably has the ability to communicate with other computer systems on the Internet. Depending on the exact functionality provided, the wireless device may be referred to as a data messaging device, a two-way radio calling device, a wireless e-mail device, a cell phone with email capabilities. sending a data message, a wireless Internet device, or a data communication device, as examples.
When the UE 700 is enabled for two-way communication, it will incorporate a communication subsystem 711, including a receiver 712 and a transmitter 714, as well as associated components, such as one or more antenna elements, preferably built-in or internal 716 and 718 , local oscillators (LOs) 713, and a processing module such as a digital signal processor (DSP) 720. As will be apparent to those skilled in the communications field, the particular design of the 711 communication subsystem will be network dependent. in which the device is intended to operate. For example, UE 700 may include a communication subsystem 711 designed to operate in the GPRS network or the UMTS network,
Network access requirements will also vary depending on the type of network 719. For example, in UMTS and GPRS networks, network access is associated with a UE 700 subscriber or user. For example, a GPRS mobile device requires It is therefore a subscriber identity module (SIM) card in order to operate in a GPRS network. In UMTS, a USIM or SIM module is required. In CDMA, a BAD card or module is required. These will be referred to as a UIM interface here. Without a valid UIM interface, a mobile device cannot be fully functional. Local and non-network communication functions, as well as legally required functions (if any), such as emergency calling, may be available, but the 700 mobile device will be unable to perform any other functions involving communications over the 700 network. The interface UIM 744 is typically similar to a card slot in which a card can be inserted and ejected like a floppy disk or PCMCIA card. The UIM card can have approximately 64K of memory and hold many key configurations 751, and other information 753, such as an identity, and subscriber related information.
When the required network registration or activation procedures have been completed, the UE 700 can send and receive communication signals over the network 719. The signals received by the antenna 716 through the communication network 719 are fed into the receiver 712, which it can perform common receiver functions such as signal amplification, frequency downconversion, filtering, channel selection and the like, and, in the example system shown in Figure 7, an analog-to-digital (A/D) conversion. An A/D conversion of a received signal allows more complex communication functions, such as demodulation and decoding, to be performed on the DSP 720. In a similar way, the signals to be transmitted are processed, including modulation and encoding, by example, by the DSP 720, and introduced into the transmitter 714 for digital-to-analog conversion, frequency upconversion, filtering, amplification, and transmission over the communication network 719 through the antenna 718. The DSP 720 not only processes communication signals, but also provides receiver and transmitter control. For example, the gains applied to communication signals at receiver 712 and transmitter 714 can be adaptively controlled through automatic gain control algorithms implemented in the DSP 720.
Network 719 can still communicate with multiple systems, including a server 760 and other elements (not shown). For example, the 719 network can communicate with an enterprise system and a web client system so as to accommodate multiple customers with varying levels of service.
UE 700 preferably includes a microprocessor 738 which controls the overall operation of the device. Communication functions, including at least data communications, are performed through communication subsystem 711. Microprocessor 738 also interacts with other device subsystems, such as display 722, flash memory 724, random access memory (RAM ) 726, the auxiliary input/output (I/O) subsystems 728, the serial port 730, the keyboard 732, the speaker 734 , the microphone 736, a short-range communications subsystem 740, and any other device subsystems generally designated as 742.
Some of the subsystems shown in Figure 7 perform communication-related functions, while other subsystems may provide "resident" or device-related functions. Notably, some subsystems, such as the keyboard 732 and the display 722, for example, can be used for communication-related functions, such as the input of a text message for transmission over a communication network, and functions residing on the device, such as a calculator or a to-do list.
The operating system software used by microprocessor 738 is preferably stored in persistent storage, such as flash memory 724, which may instead be read-only memory (ROM) or a similar storage element (not shown) . Those skilled in the art will appreciate that the operating system, device-specific applications or parts thereof can be temporarily loaded into a volatile memory, such as RAM 726. Received communication signals can also be stored in RAM 726. unique identifier is also preferably stored in read-only memory.
As shown, flash memory 724 can be wool. segregated into different areas for computer programs 758 and program data storage 750, 752, 754 and 756. These different types of storage indicate that each program can allocate a portion of flash memory 724 for its own data storage requirements. The microprocessor 738, in addition to its operating system functions, preferably allows the execution of software applications on the mobile device. A predetermined set of applications that control basic operations, including at least voice and data communication applications, for example, will normally be installed on the UE 700 during manufacturing. A preferred app might be a personal information manager (PIM) app having the ability to organize and manage data items relating to the mobile device user, such as, but not limited to, email, calendar events, voicemails, appointments and to-do items. Naturally, one or more memory stores would be available on the mobile device to facilitate the storage of PIN data items. Such a PIN 5 application would preferably have the ability to send and receive data items over wireless network 719. In a preferred embodiment, PIM data items are seamlessly integrated, synchronized and updated via financial transaction 719, with the corresponding mobile device user data items stored on or associated with a main computer system. Other applications can also be loaded onto the 700 mobile device via network 719, an auxiliary I/O subsystem 728, serial port 730, short range communications subsystem 740, or £5 any other suitable subsystem 742, and installed by a user in RAM 726 or, preferably, a non-volatile storage (not shown) for execution by the microprocessor 738. This flexibility in installing the application increases the functionality of the device and can provide improved on-device functions, communication related functions, or both. For example, secure communication applications can allow e-commerce functions and other financial transactions such as these to be carried out using the UE 700. These applications however, as stated above, in many cases need to be approved by a utility company.
In a data communication mode, a received signal, such as a text message or a web page transfer (via download), will be processed by communication subsystem 711 and input into microprocessor 738, which preferably still processes the signal received for extraction to the display 722, or alternatively to an auxiliary I/O device 728. A user of the UE 700 can also compose data items such as email messages, for example, using the keyboard 732, which preferably is a full alphanumeric keypad or a telephone type keypad, together with the display 722 and possibly an auxiliary I/O device 728. These composite items can then be transmitted over a communication network 10 via of the communication subsystem 711.
For voice communications, the general operation of the UE 700 is similar, except that received signals are preferably extracted to a speaker 734, and signals for transmission are generated by a microphone <15 736. Alternative I/O subsystems A voice or audio signal, such as a voice message recording subsystem, may also be implemented in the UE 700. Although a voice or audio signal output is preferably performed primarily through speaker 734, display 722 20 may also be used for providing an indication of the identity of a calling party, the duration of a voice call or other information related to a voice call, for example.
Serial port 730 in Figure 7 would typically be implemented on a personal digital assistant (PDA) type mobile device for which synchronization with a user's desktop computer (not shown) might be desirable. A port 730 such as this would allow a user to set preferences via an external device 30 or a software application and would extend the capabilities of the mobile device 700 by providing information or software transfers (via download) to the UE 700, otherwise in addition to through a wireless communication network. The alternative transfer path (via download) can be used, for example, to load an encryption key into the device via a direct and thus reliable and reliable connection, to thereby allow a secure communication of device.
Alternatively, serial port 730 could be used for other communications, and could include a universal serial bus (USB) as a port. An interface is associated with serial port 730.
Other communications subsystems 740, such as a short-range communications subsystem, is an additional optional component which can provide communication between the UE 700 and different systems or devices, which need not necessarily be similar devices. For example, subsystem 740 may include an infrared device and associated circuitry and components or a Bluetooth™ communication module for the provision of communication with similarly enabled systems and devices.
Reference is now made to Figure 8. Figure 8 is a block diagram of a communication system 800 that includes a UE 802 which communicates over the wireless communication network.
The UE 802 communicates wirelessly with one or multiple Node Bs 806. Each Node B 806 is responsible for air interface processing and some radio resource management functions. Node B 806 provides functionality similar to a base station transceiver in GSM/GPRS networks.
The wireless link shown in communication system 5800 of Figure 8 represents one or more different channels, typically different radio frequency (RF) channels, and associated protocols used between the wireless network and the UE 802. An air interface Uu 804 is used between UE 802 and Node B 806.
An RF channel is a limited resource that must be conserved, typically due to limits on the overall bandwidth and limited battery power of the UE 802. Those of skill in the art will appreciate that a wireless network in actual practice can include hundreds of cells , 1.5 depending on the desired overall extent of network coverage.
All pertinent components can be connected by multiple switches and routers (not shown), controlled by multiple network controllers.
Each Node B 8 06 communicates with a network 20 radio controller (RNC) 810. The RNC 810 is responsible for controlling the radio resources in its area. One RNC 810 controls multiple Node B 806.
The RNC 810 in UMTS networks provides functions equivalent to base station controller (BSC) functions in GSM / GPRS networks. However, an RNC 810 includes more intelligence, including, for example, managing autonomous point-to-point transfers without involvement of MSCs and SGSNs.
The interface used between Node B 806 and RNC 810 is an 808 lub interface. A signaling protocol of NBAP 30 (application part of Node B) is primarily used, as defined in 3GPP TS 25.433 V3.11.0 (2002 -09) and TS 25.433 V5.7.0 of the 3GPP (2004-01). A universal terrestrial radio access network (UTRAN) 820 comprises the RNC 810, the Node B 806 and the air interface Uu 804.
Circuit switched traffic is routed to the mobile switching center (MSC) 830. The MSC 830 is the computer that makes the calls, and retrieves and receives data from the subscriber or the PSTN (not shown).
The traffic between the RNC 810 and the MSC 830 uses the lu-CS 828 interface. The lu-CS 828 interface is the circuit switched connection for carrying (typically) voice and signaling traffic between the UTRAN 820 and the core network of voice. The main signaling protocol used is RANAP (part of Radio Access Network Application). The RANAP protocol is used in UMTS signaling between the 821 core network, which can be an MSC 830 or an SGSN 850 (defined in more detail below) and the UTRAN 820. The RANAP protocol is defined in TS 25.413 of 3GPP V3.11.1 20 (2002-09) and TS 25.413 V5.7.0 of 3GPP (2004-01).
For all 802 UEs registered with a network operator, permanent data (such as a UE 802 user profile) as well as temporary data (such as a current UE 802 location) are stored in a home location record. (HLR) 838. In the case of a voice call to the UE 802, the HLR 838 is consulted to determine the current location of the UE 802. A visitor location register (VLR) 836 of the MSC 830 is responsible for a group of location areas, and stores the data 30 of those mobile stations that are currently in their area of responsibility. This includes portions of the permanent mobile station data that were transmitted from the HLR 838 to the VLR 836 for faster access. However, the VLR 836 of MSC 830 can also assign and store local data, such as temporary IDs. The UE 802 is also authenticated in system access by the HLR 838.
Packet data is routed through the service GPRS support node (SGSN) 850. The SGSN 850 is the gateway between the RNC and the core network in a GPRS 10 / UMTS network and is responsible for delivering packets from data to and from the UEs in your geographic service area. The lu-PS 848 interface is used between the RNC 810 and the SGSN 850, and is the packet switched connection to (typically) carry data traffic and signaling between the UTRAN 820 and the 15v core data network. The main signaling protocol used is RANAP (described above).
The SGSN 850 communicates with the Gateway GPRS Support Node (GGSN) 860. The GGSN 860 is the interface between the UMTS / GPRS network and other networks such as the Internet or private networks. The GGSN 860 is connected to a PDN 870 public data network via a Gi interface.
Those of skill in the art will appreciate that the wireless network can be connected to other systems, possibly including other networks, not explicitly shown in Figure 8. A network will normally be transmitting at least some type of radio call and system information on a one-to-one basis. continuous, even if there is no actual exchanged packet data. Although the network consists of many parts, these parts all work together to result in certain behaviors on the wireless link. Fig. 11 illustrates a representation, shown generally at 1102, representing the operation of the UE in line with multiple packet data communication service sessions. Here, two packet data services, 5 each associated with a particular PDP context designated as PDP], and PDP2 are concurrently active. Graphic 1104 represents the PDP context enabled for the first packet data service, and graphic 1106 represents the radio resource allocated for the first packet data service. And the graphic 1108 represents the PDP context enabled for the second packet data service, and the graphic 1112 represents the radio resource allocated to the second packet data service. The UE requests a radio access bearer allocation by means of a service request, indicated by segments 1114. And the UE also requests a radio bearer service release, indicated by segments 1116 in line with a modality of the present exhibition. Service requests and service releases for the 20 separate services are independent of each other, that is, they are generated independently. In the example illustration of Figure 11, the PDP context and the radio resource for the associated PDP context are assigned at substantially concurrent times. And the release of radio resource is granted upon a request by the UE, as shown, or when the RNC (radio resource controller) decides to release the radio resource.
In response to a radio resource release request, or other decision to release the radio resource, the network selectively disconnects the radio resource associated with the packet data service. Radio release requests are made on a radio access bearer by radio access bearer basis and not on an entire signaling link basis, thereby allowing for improved control of resource allocation granularity.
In the example implementation, a single packet data service is additionally formable as a primary service and one or more secondary services, such as indicated by resignations 1118 and 1122. plus primary and secondary services whose radio resource allocations are no longer needed or otherwise desired to be released. An efficient radio resource allocation in this way is provided. Furthermore, an optimal processor utilization in the UE is provided, since the processor power that would have been allocated to unnecessary processing can now be better utilized for another 20 purposes. Figure 12 illustrates parts of the communication system 800, specifically, the UE 802 and the radio network controller (RNC) / SGSN 810/850 operating in line with an embodiment of the present disclosure relating to multiple 25 data service sessions of contiguous packets. The UE includes apparatus 1126 and the RNC/SGSN includes apparatus 1128 of an embodiment of the present disclosure. The elements forming apparatus 1126 and 1128 are functionally represented, implementable in any desired manner, including by algorithms executable by processing circuits, as well as hardware or firmware implementations. Apparatus elements 1128, although represented as embodied in the RNC/SGSN, in other implementations are formed elsewhere in other network locations, or distributed over more than one network location.
Apparatus 1126 includes a detector 1132 and a transition indication emitter 1134. In an example implementation, elements 1132 and 1134 are embodied in a session management layer, e.g. ) in UMTS, from the EU.
In another example implementation, the elements are embodied in an access layer (AS) sublayer. When implemented as the AS sublayer, elements are implemented as part of a .15 connection manager, shown in 1136. When implemented in this way, elements do not need to be aware of PDP context behavior or application layer behavior .
The detector detects, when a determination is made, that it is to send a transition indication associated with a packet communication service. The determination is made, for example, in an application layer, or another logical layer, and provided to the session management layer and the detector realized there. Indications of detections 25 made by the detector are provided to the radio resource release indication sender. The issuer generates and causes the UE to send a transition indication that forms the service release request 1116, shown in figure 11.
In a further implementation, the transition indication includes a cause field containing a cause, such as any of the aforementioned causes described herein and above, as appropriate, or the cause field identifies a preferred state in which the UE prefers that the network causes the UE to undergo a transition.
Apparatus 1128 embodied in the network includes an examiner 1142 and a grantor 1144. The examiner examines the transition indication when received there. And the transition grantor 1144 selectively operates to transition the UE, as required, in the transition indication.
In an implementation where the signaling is formed at a radio resource control (RRC) layer, the radio network controller (RNC), rather than the SGSN, 15w performs the scan and performs the transition of the UE. And correspondingly, the apparatus embodied in the UE is formed at the RRC layer, or the apparatus otherwise causes the generated indication to be sent at the RRC level.
In an example control flow, a higher layer informs the NAS/RRC layer, as appropriate, that the radio resource allocated to a particular PDP context is no longer required. An RRC layer indication message is sent to the network. The message includes an RAB ID or an RB ID that, for example, identifies the packet data service, for the radio resource controller. And, in response, an operation of the radio network controller triggers a procedure to resolve to terminate a radio resource release, a radio resource reset, or a radio resource control connection release (RRC) message to be returned to the UE. The RNC procedure, for example, is similar or equivalent to the procedure set out in 3GPP TS 23.060, Section 9.2.5. The RAB ID advantageously used as the ID is the same as the network service access point identifier (NSAPI) which identifies the associated PDP context, and application layers are generally aware of NSAPI.
In a specific example, a radio resource release indication formed in, or otherwise provided to, the RRC layer and sent in the RRC layer is represented, together with associated information, below. The indication, when embodied in the RRC layer, is also referred to as, for example, a radio resource release indication.
Figure 13 illustrates a message sequence diagram, shown generally at 1137, representing an example signaling generated in line with the release of radio resources associated with a PDF context, such as that shown graphically in part of the graphical representation shown in figure 11. The release is initiated by the UE or the RNC, or another UTRAN entity. When initiated in the UE, for example, the UE sends a radio resource release indication to the UTRAN.
Upon initiation, a Radio Access Bearer (RAB) Release Request is generated, and sent, indicated by segment 1138 by the RNC / UTRAN and sent to the SGSN. In response, a RAB assignment request is returned, indicated by segment 1140, to the RNC / UTRAN. And then, as indicated by segment 1142, the radio resources extending between the UE 802 and the UTRAN are released. A response is then sent as indicated by segment 1144. Figure 14 illustrates a message sequence diagram shown generally at 1147, similar to the message sequence diagram shown in Figure 13, but here 20 in which features from a final PDP context are released.
Upon initiation, the RNC generates an LU release request 1150 which is communicated to the SGSN and, in response to this, the SGSN returns an LU release command, indicated by segment 1152. After that, and as indicated by segments 1154, the radio bearer formed between the UE and the UTRAN is released. And, as indicated by segment 1156, the RNC / UTRAN returns a completed lu release to the SGSN. Figure 15 illustrates a method flowchart, shown generally at 1162, representative of the process of an embodiment of the present disclosure for releasing allocated radio resources in line with a PDP context.
After the start of the process, indicated by block 1164, a determination is made, indicated by decision block 1166, as to whether a radio resource release indication has been received. If not, the branch is not followed to end block 1168.
Conversely, if a radio access bearer release has been requested, the yes branch will be taken to decision block 1172. In decision block 1172, a determination is made as to whether the radio access bearer is to be released is the final radio access bearer to be released. If not, the branch is not followed to block 1178, and the preferred state is set. Then, radio access bearer clearance procedures are performed, such as that shown in figure 13, or such as that described in Section 23.060 of the 3GPP document, subitem 9.2.5.1.1.
Conversely, if a determination is made in decision block 1172 that the RAB is the last to be released, the branch yes will be followed to block 1186, an lu release procedure such as that shown in Figure 14, or such as that described in Section 23.060 of the 3GPP document, subitem 9.2.5.1.2 is carried out. Figure 16 illustrates a method flowchart, shown generally at 1192, representative of the process of a procedure in the present disclosure for releasing allocated radio resources in line with a PDP context.
After the start of the process, indicated by block 1194, a determination is made, indicated by decision block 1196, as to whether there is a RAB (Radio Access Bearer) to release. If not, the branch is not followed to end block 1198.
Conversely, if a radio access bearer release has been requested, the yes branch will be followed to decision block 1202. In decision block 1202, a determination is made as to whether the radio access bearer is to be released is the final radio access bearer to be released. If not, the branch is not followed to block 1204, where the RAB list is regulated, block 1206, where the preferred state is regulated, and block 1208, where the radio access bearer release procedures are performed , such as that shown in figure 13, or such as that described in Section 23.060 of the 3GPP document, subitem 9.2.5.1.1.
Conversely, if a determination is made at decision block 1202 that the RAB is the last to be released, the yes branch will be followed to block 1212, and the domain will be set to PS (packet switched). Then, as indicated by block 1214, a release cause is regulated. And, as indicated by block 1216, a SIGNALING CONNECTION RELEASE INDICATION is sent on a DCCH. An lu release procedure, such as the one shown in figure 14 or such as that described in Section 23.060 of the 3GPP document, subitem 9.2.5.1.2 is performed. Figure 17 illustrates a method, shown generally at 1224, representative of the method of operating an embodiment of the present disclosure. The method facilitates an efficient use of radio resources in a radio communication system that provides a concurrent round of a first packet service and a second packet service. First, and as indicated by block 1226, a detection is made of a selection to release a radio resource associated with a packet service selected from the first packet service and the second packet service. Then, as indicated by block 1228, a radio resource release indication is sent in response to detecting the radio resource release selection.
Then, at block 1212, the radio resource release indication is examined, and then, at block 1214, a . radio bearer release grant is selectively granted.
In an additional modality, the network may initiate a transition based on receipt of an indication from the user equipment or another network element and a radio resource profile for the user equipment.
An indication as received from user equipment or another network element could be any of the different transition indications described above. The indication can be passive and thus merely a blank indication that a less battery intensive radio state should be entered. Alternatively, the indication could be part of the regular indications sent from the UE, which the network determines, possibly over time or a number of indications received, and the UE radio resource profile to enter into. a less battery intensive radio state or a radio resource. Alternatively, the indication could be dynamic and provide information to the network element about a preferred state or mode to which a transition would be made. As with the above, the indication could contain a cause for the indication (eg, normal or abnormal). In a further embodiment, the indication could provide other information about a radio resource profile, such as a probability that the user equipment is correct about the ability to transition to a different state or mode, or information about the ) application(s) that triggered (triggered) the indication.
An indication of another network element could include, for example, an indication of a push-to-talk or media network entity. In this example, the indication is sent to the network entity responsible for the transition (for example, the UTRAN) when traffic conditions 20 allow. This second network entity could look at traffic at an Internet Protocol (IP) level to determine if and when to send a transition indication.
In an additional modality, the indication from the 25 UE or a second network element could be implicit, rather than explicit. For example, an indication of transition may be implied by the network element responsible for the transition (for example, the UTRAN) from device status reports on measurements of external traffic. Specifically, a status report could include a radio link buffer status where, if no output data exists, it could be interpreted as an implicit indication. This status report could be a measurement that could be repeatedly sent from the UE which by itself does not request or indicate anything.
The indication thus could be any signal and could be application-based, radio resource-based, or a composite indication providing information concerning all applications and radio resources of user equipment. The foregoing is not meant to be limiting for any particular indication, and one skilled in the art would appreciate that any indication could be used with the present method and the disclosure.
Reference is now made to Fig. 18. The process starts at step 1801 and proceeds to step 1810, in which a network element receives the indication.
Once the network receives the indication in step 1810, the process proceeds to step 1820, in which a radio resource profile for the user equipment is optionally checked.
The term "radio resource profile" as used herein is meant to be a broad term that could apply to a variety of situations, depending on the requirements of a network element. In broad terms, the radio resource profile includes information about radio resources used by user equipment.
The radio resource profile could include either or both static profile elements and dynamic or negotiated profile elements. These elements could include a value of "ban duration and/or indication/maximum request messages per time window", which could be part of the radio resource profile, within or apart from the transition profile, and could be 5 traded or static.
Static profile elements can include one or more of quality of service for a radio resource (eg, RAB or RB), a PDP context, an APN that the network is aware of, and a subscriber profile.
As will be appreciated by those skilled in the art, various levels of quality of service could exist for a radio resource and the level of quality of service could provide information to a network as to whether it is to transition to a different state or mode.
Thus, if quality of service is in the background, the network element may consider transitioning to idle mode more readily than if quality of service were set to interactive. Furthermore, if multiple radio resources had the same quality of service, this could provide an indication to the network as to whether to transition the mobile device to a more suitable state or mode or to disconnect the radio resources. In some modalities, a primary and a secondary PDP context could have a different quality of service, 25 which could also affect the decision as to whether to perform a state/mode transition.
Furthermore, the APN could provide the network with information about the typical services that the PDP context uses. For example, if the APN is xyz.com, where xyz.com typically 3 0 is used for the provision of data services, such as email, this could provide an indication to the network as to whether or not to transit to a different state or mode. This could also indicate routing characteristics.
In particular, the present method and apparatus can use the access point name (APN) specified by the UE for the regulation of the transition profile between various states. This can be another way to describe the UE signature. As will be appreciated, the home location register (HLR) can store relevant information about subscribers, and could provide the radio resource controller (RNC) with the UE signature. subscription information centrally.
Using the HLR or another network entity, information is preferably pushed to the other network components, such as the RNC and the SGSN, which map the signature information to the relevant physical parameters used during a data exchange. The UTRAN could include or have access to a database or a table, in which various APNs or QoS parameters could be linked to a specific transition profile. Thus, if the UE is an always on device, this will be evident from the enumerated application 25, and an appropriate transition profile for that APN could be stored in the UTRAN as part of the radio resource profile or be remotely accessible by the UTRAN. Similarly, if QoS or a portion of the QoS parameter is used, or a dedicated message sent with a profile, this could mean to the UTRAN that a particular transition profile is desired, based on a database query. data or a query on a table. Additionally, a multiplicity of behaviors in addition to the connected state transition profile of RRC can be specified by this means. These include, but are not limited to: rate adaptation algorithms (increment periodicity - increment size); initial granted radio bearer; maximum granted radio bearer; minimize call set-up time (avoid unnecessary steps such as traffic volume measurements); and the air interface (GPRS / EDGE / UMTS / HSDPA / HSUPA 15 . / LTE, etc.) .
Also, if there are multiple PDP contexts that have different QoS requirement but share the same APN weighted image error address, such as a primary context, a secondary context, and so on, a different transition profile may be used for each context. This could be signaled to the UTRAN via QoS or dedicated messages.
If multiple active PDP contexts are used concurrently, the lowest common denominator 25 among the contexts can be used. For an RRC state transition, if an application has a first PDP context that is associated with a transition profile in which the system moves from CELL_DCH state to CELL_PCH state or Idle state quickly, and a second context If PDP is associated with a transition profile in which the system is to stay in the CELL_DCH state longer, the second profile in which the CELL_DCH state is held longer will suppress the first profile.
As will be appreciated by those skilled in the art, the lowest common denominator can be considered in two different ways. The lowest common denominator as used here implies a longer time required before a transition to a different state. In a first modality, the lowest common denominator can be the lowest of the active PDFs. In an alternative modality, the lowest common denominator can be the lowest of the PDPs that actually have active radio resources. Radio resources could be multiplexed in many different ways, but the end result is the same.
An example case for these methods can be described for always-on devices. As described, multiple APNs or QoS parameters can be bound to specific always-on behavior. Initially consider granted radio capabilities that may be desirable based on an 'always on' profile. The network now has a way of 'knowing' that data bursts are short and bursty for always-on applications such as email. For those skilled in the art, it is clearly seen that, given this information, there is no incentive to save code space for network trunking efficiency. Thus, a maximum rate can be allocated to an always-on device with little risk of not reserving enough code space for other users. Additionally, the UE benefits from receiving data faster and also saves battery life due to the shorter 'on time'. Again, for those skilled in the art, high data rates have very little effect on the current draw, as 5 power amplifiers are fully biased regardless of data rate.
In the above modality, a lookup table can be used by the UTRAN for determining the resource control profile for radio resource(s) to be assigned to different applications for a given RRC connection to the HUH. The profile can be based on a user signature and stored on the network side in a network entity such as the HLR, or alternatively in the RNC as the RNC will have more up-to-date traffic resources available (ie , data rates that may be granted). If higher data rates can be obtained, shorter expirations may be possible.
Instead of an APN, other alternatives, such as quality of service (QoS) parameters regulated in a packet data protocol (PDP) context trigger or modified PDP context, can be used. The QoS field can still include the "allocation retention priority (one service data unit could be used to infer traffic data volumes)" of QoS in a case of multiple PDP contexts sharing the same APN address or a subscriber profile for tuning the transition profile. Other alternatives include dedicated messages such as the indication message above for signaling a resource control profile and information such as a ban duration and/or indication/maximum request per time window value messages .
The transition profile included in the radio resource profile could further include whether the UE state should be a transition at all, based on the application type. Specifically, if the user equipment is being used as a data modem, a preference may be set on the user equipment for transition indications not to be sent, or if a knowledge of the preference is maintained on the network, that any transition indication received from the UE while being used as a data modem should be ignored. Thus, the nature of the applications being run on the user equipment could be used .15 as part of the radio resource profile.
An additional parameter of a transition profile could involve the type of transition. Specifically, in a UMTS network, user equipment may prefer to go into a CELL_PCH state rather than going into an idle state for various reasons. One reason could be that the UE would need to connect to a CELL_DCH state more quickly if data needs to be sent or received, and thus moving to a CELL_PCH state will save network and battery signaling resources while still providing a quick transition to the CELL_DCH state. The above is applicable in non-UMTS networks and can provide a transition profile between various connected and idle states.
The transition profile can also include a number of 30 timers, including but not limited to ban duration and/or maximum prompt/request messages per time window, delay timers and inactivity timers. Delay timers provide a period which the network element will wait before transitioning to a new state or mode. As will be appreciated, even if the app has been inactive for a particular period of time, a delay can be beneficial in order to ensure that no future data is received or transmitted from the app. An inactivity timer could measure a predetermined period of time in which no data is received or sent by an application. If data is received before the inactivity timer expires, typically the inactivity timer will be reset. Once the .15 inactivity timer expires, the user equipment can then send step indication 1810 to the network. Alternatively, the user equipment may wait for a certain period of time, such as that defined for the delay timer, before sending the step indication 1810.
Also, the delay timer or ban duration and/or time window indication/request messages could vary, based on a profile that is provided for the network element. Thus, if the application that requested a transition to a different mode or state is a first type of application, such as an email application, the delay timer on the network element can be set to a first delay time, while if the application is of a second type, such as an instant messaging application, the delay timer can be set to a second value. The values of the ban duration and/or indication/maximum request messages per time window, delay timer or inactivity timer 5 could also be derived by the network based on the APN used for a particular PDP.
As those skilled in the art will appreciate processing, the inactivity timer could similarly vary based on the application used. Thus, an email application may have a shorter inactivity timer than a browser application since the email application is waiting for a discreet message after which it may not receive data. Conversely, the browser application can use 15 data even after a longer delay and thus require a longer inactivity timer.
The transition profile can also include a probability that a user equipment is correct requesting a transition. This could be based on 20 complicated statistics about the accuracy rate of a particular user equipment or application on the user equipment.
The transition profile can still include multiple discontinuous receive time (DRX) values. Furthermore, a progression profile for DRX times can be provided in a transition profile.
The transition profile could be defined on an app-by-app-by-app basis or be a composite of multiple apps on the user's equipment.
As will be appreciated by those skilled in the art, the transition profile could be dynamically created or modified when a radio resource was allocated, and could be done under subscription, PS registration, PDP activation, RAB or RB activation or changed in 5 progress to the PDP or the RAB / RB. The transition profile could also be part of the step 1810 indication. In this case, the network may consider the preferred RRC state indication to determine whether to allow the transition and for what state/mode. A modification could also 10 occur based on available network resources, traffic patterns, among others.
The radio resource profile is therefore comprised of static and/or dynamic fields. The radio resource profile used by a particular network may vary from other networks and the above description is not meant to limit the present method and system. In particular, the at radio resource profile could include and exclude several elements described above. For example, in some cases, the radio resource profile will merely include the quality of service for a particular radio resource and will not include other information. In other cases, the radio resource profile will only include the transition profile. In still other cases, the radio resource profile will include everything from quality of service, APN, 25 PDP context, transition profile, and so on.
Optionally, in addition to a radio resource profile, the network element could also use safeguards to avoid unnecessary transitions. These safeguards could include, but are not limited to, the number of referrals received in a predetermined time period II, the total number of referrals received, traffic patterns, and historical data.
The number of indications received in a predetermined period of time could indicate to the network that a transition should not occur. Thus, if the user equipment has sent, for example, five indications in a time period of thirty seconds, the network may consider that it should ignore the indications and not make any transitions. Crash, the network may determine that it is to indicate to the UE that it should not send any further indications indefinitely or for some configured or pre-defined period of time. This could be independent of any "ban and/or indication/request duration messages of maximum .15 per time window" in the UE.
Furthermore, the UE could be configured to not send further indications for a configured, pre-defined or negotiated period of time. The configuration of the UE could be exclusive to the safeguards on the network side described above.
Traffic patterns and historical data could provide an indication to the network that a transition should not occur. For example, if the user has received a significant amount of data in the past between 8:30 am and 8:35 am Monday through Friday, if indication 25 is received at 8:32 am on Thursday, the network may decide not to transit user equipment as more data is likely before 8:35 am .
If multiple radio resources are allocated to the user equipment, the network may need to consider the complete radio resource profile for the user equipment. In this case, the radio resource profiles for each radio resource can be examined and a composite transition decision made. Based on the 5 radio resource profile of one or multiple radio resources, the network can then decide whether or not to transition.
An Additional Limitation on Transition Indications As previously described, there are several mechanisms by which a UE may have transitioned to its current 10 RRC state. The initiation for the transition may have been entirely network-driven, for example, as a result of observed inactivity. In this example, the network maintains inactivity timers for each of the RRC states. If the inactivity timer for the current RRC state of the UE expires, then the network will send an RRC reset message to transition the UE to a different state. Alternatively, transition initiation may have been commanded by the UE using a transition indication mechanism as described above 20 (for example, with the use of a transition indication message). Once the network has control of the RRC state machine, in this case, the UE can send an indication to the network that it does not need to be kept in the current RRC state and is requesting a transition to a 25 RRC state that consumes less drums.
In one embodiment, a limitation is imposed on the UE's ability to transmit a transition indication which is a function of whether or not the UE has gone through the most recent transition in its current state as a result of a transition indication previously transmitted by the UE.
In another embodiment, the number of transition indications the UE can send in its current state is a function of whether or not the UE went through the most recent transition to its current state as a result of a transition indication previously transmitted by the UE .
In another embodiment, the number of transition indications the UE can send in specific states is limited regardless of how the UE went through the most recent transition to its current state where the current state is one of the specific states to which this limitation applies.
Prohibition of any transition indication following an RRC state change from a previously transmitted transition indication.
In some embodiments, if the UE is in its current state as a result of having previously transmitted a transition indication, the UE will be prohibited from transmitting any further transition indications while in this current state.
The UE may maintain a flag type indicator, a bit token or other indicator which indicates whether the UE is allowed to send transition indications to the network while it remains in its current state. If the UE is reconfigured by the network to a new RRC state (for example, the network sends a reconfiguration message to the UE to effect a transition to the new RRC state) after sending a transition indication to the network, then, this flag type indicator, this bit token or other indicator is sent (or alternatively cleared), indicating that the UE is not allowed to send further transition indications while it remains in this current state. If the UE changes its RRC state due to a data transaction request by the UE (for example, because its buffer shows that it has data to be sent) or by the network (for example, because the network radioed the UE ) then this indicator will be cleared (or alternatively set) to indicate that the UE is once again allowed to send a transition indication to the network.
Prohibition of more than a predetermined number of transition indications following an RRC state change from a previously transmitted transition indication.
In some embodiments, if the UE is in its current state as a result of having previously transmitted a transition indication, the UE will be prohibited from transmitting anything more than a predetermined maximum number of additional transition indications while the network maintains the UE in this same current state. In some embodiments, the predetermined number is rigidly encoded in the UE. In other embodiments, the predetermined number is configured by the network, and is subject to change as the UE moves between different networks. Network configuration can take place, for example, using a signaling message directly to the mobile station, or as part of a broadcast message.
The UE maintains a flag type indicator, a bit token or other indicator which indicates whether the UE is allowed to send transition indications to the network, as long as it remains in its current state. If the UE has transitioned to this current state as a result of sending a transition indication in a previous state, then this flag type indicator, this bit token or other indicator will be set. If the UE has transitioned to this current state as a result of normal network driven transitions, based on inactivity timers, for example, then this flag type indicator, this bit token or other indicator will not be set, and will not there will be restrictions on the number of transitional indications that the UE can send in its current state.
In the case where the flag type indicator, the bit token or the indicator is set indicating that the UE is only allowed to send a fixed number of transition indications to the network, while remaining in this current 15* state, the UE, furthermore, it can maintain a counter which counts the number of transition indications that are sent by the UE after it has determined that it has just transitioned to its current state as a result of a previously transmitted transition indication.
In this example, once in the current state, if the UE subsequently wants to transmit a transition indication from this current state, it will first look at the flag type indicator, bit token or other indicator to see if it has limited the number of 25 transition indications it can send to the network while it remains in its current state. If limited, then the UE will keep a count of the number of transition indications it sends provided, since the network response to the transition indicator is to move the UE to its current RRC state (in the case where the UE needs to transition to another state of RRC to send the transition indication message) or to leave the UE in its current state (in which case the UE can send the transition indicator in its current state).
When the UE compares the value of its transition indication counter with the predetermined maximum number of additional transition indications allowed (possibly indicated by a flag type indicator, a bit token or other indicator), the value of the transition will be greater than this predetermined maximum number, then the UE will subsequently not send further transition indications to the network.
If the result of a transition indication sent by the UE is that the UE transitioned to an RRC state different from its current state (for example, by a reset message sent by the network) before sending the transition indication, that is more battery-intensive than the current state, then the counter will reset and the process will start again in the new current state. This would be the case, for example, if the end result is that the UE is reset from PCH to CELL_FACH.
If the UE changes the state of RRC due to a data transaction request by the UE (for example, because its buffer shows that it has data to be sent) or by the network (for example, because the network radioed the UE) , then this indicator will be cleared (or alternatively set) to indicate that the UE is once again allowed to send a transition indication to the network and the counter is reset. Prohibition of more than a predetermined number of transition indications.
In some embodiments, the UE is prevented from transmitting more than a predetermined maximum number of transition indications, while the network keeps the UE in its same current state. In some embodiments, the predetermined number is hard coded in the UE. In other embodiments, the predetermined number is configured by the network, and is subject to change as the mobile station moves between different networks. Network configuration can take place, for example, using a signaling message directly to the mobile station, or as part of a broadcast message.
The UE maintains a counter which counts the number of transition indications that are sent by the UE later from its current state. Therefore, upon a transition to the current state, and the UE subsequently wants to transmit a transition indication from its current state, then the UE keeps an account of the number of transition indications it sends as long as the network response to the transition indicator either to return the UE to its current RRC state (in the case where the UE needs to transition to another RRC state to send the transition indication message) or to leave the UE in its current state (in the case where the UE can send the transition indicator in its current state).
If, when the UE compares the value of its transition indication counter with the predetermined maximum number of additional transition indications, the value of the transition indication counter is greater than this predetermined maximum number, then the UE will not send subsequently additional transition indications for the network.
If the result of a transition indication sent by the UE is that the UE is reset to an RRC state different from its current state before sending the transition indication, and the different RRC state is more battery intensive than the current state, then the counter will be reset and the process will start again in the new current state.
If the UE changes the state of RRC due to a data transaction request by the UE (for example, because its buffer shows that it has data to be sent) or by the network (for example, because the network radioed the UE) , then this indicator will be cleared (or alternatively set) to indicate that the UE is once again allowed to send a transition indication to the network and the counter is reset.
If there is a state transition that resulted from having previously transmitted a transition indication it can be used to enable/disable or limit the further transmission of transition indications in several ways: 1) A prerequisite to allow the transmission of a transition indication. transition which is the previous state transition must not have been the result of the UE having previously transmitted a transition indication. This prerequisite can be combined with other prerequisites or prohibitions, so that a prerequisite satisfaction alone may not necessarily allow the UE to transmit a transitional indication. 2) A prerequisite for allowing the transmission of a transition indication is that if the previous state transition was the result of the UE having previously transmitted a transition indication, no more than a defined number of transition indications will have been transmitted to the UE. This prerequisite can be combined with other prerequisites or prohibitions, so that a fulfillment of the prerequisite just does not necessarily allow the UE to transmit a transitional indication. 3) If the previous state transition was the result of the UE having previously transmitted a transition indication, prohibit transmission of a transition indication. This is logically equivalent to 1) above. This ban can be combined with other prerequisites or bans, as if the ban were not triggered, that alone might not necessarily allow the UE to transmit a transitional indication. 4) if the previous state transition was the result of the UE having previously transmitted a transition indication, prohibit the transmission of anything more than a defined number of transition indications. This is logically equivalent to 2) above. This ban can be combined with other prerequisites or bans, as if the ban were not triggered, that alone might not necessarily allow the UE to transmit a transitional indication. 5) If the previous state transition was not commanded by UE, allow transmission of a transition indication. 6) If the previous state transition was the result of the UE having previously transmitted a transition indication, allow transmission of only up to a defined number of transition indications. 7) For certain RRC states, allow transmission of only up to a defined number of transition indications. Interaction with Prohibition Timer
As indicated above, the prerequisite based on transition of state or prohibition can be combined with 10 other prerequisites or other prohibitions. Above, arrangements have been described which prohibit the UE from sending a transition indication for the same period of time after previously sending a transition indication. In some modalities, this ban is combined with the ban/o - 15 state transition-based prerequisite described above.
For example, the use of a prohibition timer was previously described as a mechanism for prohibiting the UE from sending a transition indication for the same period of time after previously sending a transition indication, where a prohibition timer is started after transmitting a transition indication, and the UE is allowed to send another transition indication only if the prohibit timer is not running.
In some embodiments, the use of this ban timer is combined with state transition based ban as follows:
Is prior state transition the result of the UE having previously transmitted a transition indication Prohibiting the transmission of a transition indication, or prohibiting the transmission of more than a defined number of transition indications subsequent to a previous transition that was the result of the UE having previously transmitted a transition indication; and Is the ban timer running Prohibit a transmission of a transition indication.
In some modes, these are the only two bans in effect, in which case the behavior can be summarized as follows: allow transmission of a transition indication if the ban timer is not running, and the current state is not the result of a prior transition indication transmitted by the UE, or allow transmission of a transition indication if the prohibit timer is not running, and the current state was not the result of a prior transition indication transmitted by the UE, or allow transmission of a transition indication if the prohibit timer is not running, and if less than a defined number of transition indications have been transmitted subsequent to a state transition which was the result of the UE having previously transmitted a transition indication.
Maintaining Prior State Transition Cause The UE has a mechanism for maintaining an indication as to whether the current state is the result of prior transmission of a transition indication by the UE. This indication may be a previous state transition cause value stored in a memory in the UE that is accessible by a processor forming part of the UE, or a switch implemented in hardware, to name a few examples. In a specific example, the previous state transition cause is a single bit which is a first value ('1' or '0') to indicate that the previous state transition is the result of the UE having previously transmitted an indication. transition, and otherwise is a second value ('0' or '1' ) .
Prior State Transition Cause Assessment The UE has a mechanism to determine whether the current state is the result of the prior transmission of a transition indication by the UE.
If the UE has sent the transition indication, and it has been acknowledged by the network, so that the UE knows that the network has received it, then the UE may know that if it receives an RRC reconfiguration message on a fixed period of time this RRC configuration message is the result of sending the transition indication.
If the UE receives an RRC reset and has not sent (and had acknowledged) a transition indication within a predetermined period of time taken until the reset, then the UE may assume that the state transition was not in response to the transmission transitional indication by the EU.
In a first example, each time a state transition occurs as a result of a reconfiguration by the network, the UE evaluates whether the state transition was the result of the UE having previously transmitted a transition indication. If this has been the case, the UE will update the previous state transition cause to 30 indicate that the previous state transition was commanded by
HUH. If the state transition was other than the result of the UE having previously transmitted a transition indication, then the previous state transition cause will be updated accordingly.
In some embodiments, where a transition with cause value is supported, the UE determines whether it had previously sent a transition indication with a cause value for which this mechanism is to be implemented, prior to receiving this reset.
In some embodiments, the UE performs the following steps to determine whether a state transition is the result of the UE having previously transmitted a transition indication: 1) transmitting a transition indication (or a transition indication with a cause value in particular); 2) if a state transition that is consistent with the transition indication occurs within a defined transition indication transmission time interval, evaluate the state transition to be the result of the UE having previously transmitted a transition indication and, otherwise, evaluate the state transition as being other than the result of the UE having previously transmitted a transition indication.
In some embodiments, upon transmission of a transition indication, a timer is started, starting a count that regresses starting at an expiration value, or, equivalently, progressing to an expiration value. If the timer is still running when the state transition occurs, then it will be judged to be the result of the UE having previously transmitted a transition indication.
In some embodiments, either of these embodiments is implemented using a transition indication that includes a cause code to allow the UE to specify a cause for the transition indication (for example, to indicate that a data transfer or a call is completed, or that no additional data is expected for an extended period). A specific example 10 is the SIGNALING CONNECTION RELEASE INDICATION defined in Section 8.1.14 of 3GPP TS 25.331, where the cause code is the IE "Signaling Connection Release Indication Indication Cause" set to "EU requested end of PS data session"
In some modalities, any of these modalities are implemented using a transition indication that does not include a cause code. A specific example is the SIGNALING CONNECTION RELEASE INDICATION defined in Section 8.1.14 of 3GPP TS 25.331. Additional Example Determining the Mechanism for RRC State Transition
If a UE receives an RRC reset message from the network, it can determine whether it has sent a SCRI message with the cause value "UE requested end of 25 PS data session" before receiving this reset.
If the UE has sent this message, and the message has been acknowledged by the network, so that the UE knows that the network has received it, then the UE can know that if it receives an RRC reconfiguration message in a period of fixed time, this RRC reset message is the result of sending the SCRI.
If the UE is in the CELL_DCH or CELL_FACH state and has sent a SCRI which has been acknowledged, but the network does not send an RRC reset in a fixed period of time, then the UE can assume that it is currently in the state where the The network wants it to remain, and the UE may consider that the mechanism by which it remains in that state is for Rapid Dormancy purposes.
If the UE receives an RRC reset and has not sent (and acknowledged) an SCRI message in the fixed period of time leading to the reset, then the UE may assume that the state transition was not for Fast Sleep purposes. Specific Examples
With reference to the state diagram of Fig. 1, assume that a UE is initially in the CELL_DCH 122 state. After that, the UE transmits a transition indication, for example, upon determining that it has no more data to send. In response, the network recognizes the transition indication and transitions the UE to URA_PCH. In some modalities this is a direct state transition. In other embodiments, this is an indirect state transition through the CELL_FACH state. After that, the UE is not allowed to send another transition indication.
Note that, in general, the description of modalities and behavior that refer to the URA_PCH state also applies to the CELL_DCH state.
On the other hand, if the network decides by itself to transition the UE to URA PCH, for example, due to the expiration of an inactivity timer, the UE will be allowed to send a transition indication. At this point, the UE is looking to transition to INACTIVE mode from URA_PCH. However, the UE must transition to 5 CELL_FACH to send the transition indication. Remember that the purpose of the transition indication is for the UE to move to a less battery intensive state. If the network leaves the UE in CELL_FACH, this will not be a transition to a more battery efficient state (the only most battery efficient state 10 from URA_PCH being INACTIVE) and then the CELL_DCH state is not considered as being the result of a prior transmission of a transition indication. If the network transitions the UE to URA_PCH or INACTIVE mode within a defined period, then the *15 state transition will be considered to be as a result of a prior transmission of a transition indication. Another Prohibition
In some arrangements, if the UE has sent a transition indication which has been acknowledged, but the network has not sent an RRC reset in a fixed period of time, then the UE will assume that it is currently in the state in which the network wants it to remain. In some embodiments, upon this sequence of events occurring, the UE is prevented from transmitting a transition indication, although the current state cannot necessarily be the result of the UE having previously transmitted a transition indication.
In some embodiments, the prohibition described above is implemented only if the state the UE remains in is the CELL_DCH or CELL_FACH state of RRC.
State Due to Fast Dormancy In some embodiments, when the UE is in a state that is the result of a previously transmitted transition indication, the UE is said to be in a state due to invoking fast dormancy. In some embodiments, when the UE has transmitted a transition indication which is acknowledged, but the UE has not undergone a state change, the UE will also be said to be in a state due to invoking fast dormancy.
If the UE has transitioned to an RRC state (other than INACTIVE) and this has not been because of a transition indication (also referred to as a transition indication for fast dormancy purposes) then the UE will use the timer to determine when he will be allowed to send a transition indicator for fast dormancy purposes. This behavior is currently described in 3GPP TS 25.331.
If the UE has transitioned to a state of RRC (other than INACTIVE) and this was due to a transition indication, then the UE will have different restrictions on its behavior. The UE will regulate some kind of flag type indicator or indication internally, when it knows that it is in this situation. This can be referred to, for example, as an FDM (Fast Dormancy Mechanism) flag type indicator.
In one case, the UE may be prohibited from sending an additional transition indication. Alternatively, the UE may be allowed to send additional requests for a state transition, but the number of additional requests is limited to some defined number, for example one or more. The period between sending these requests is controlled by the ban timer.
If, when the UE requests a state transition 5 using the transition indication (and it has been acknowledged), the network will either leave the UE in its current RRC state (eg to CELL_FACH) or move it back to the state of RRC from which it sent transition indicator (eg UE was at 10 CELL_PCH, moved to CELL_FACH to send SRCI, then network moved UE back to CELL_PCH), then UE will decrement the number of remaining transition indication requests it is allowed to send.
If the UE moves to a state of RRC other than 15. because a data transition is initiated (for example, it receives a radio call and is responding to it, or it requests resources for a data transaction), then the UE will clear the FDM flag type indicator and the procedure will start over.
If the UE makes a transition to the CELL_FACH state to transmit a CELL_UPDATE message or an URA_UPDATE message and on network acknowledgment the UE is moved back to the CELL_PCH or URA_PCH state, then this will not clear the FDM flag type indicator.
However, if the UE makes a transition to the CELL_FACH state to transmit a CELL_UPDATE message or an URA_UPDATE message or a transition indication message, and the network subsequently leaves the UE in the CELL_FACH state, then the UE will actually clear the type indicator 30 of FDM flag and the procedure will start over.
In some cases, the UE is prevented from sending the SCRI message entirely after the UE has transitioned to a different RRC state in response to a fast dormancy request using the SCRI message with the value of 5 cause "UE requested end of session PS data" . In this case, the UE sets the FDM flag type indicator and only clears its flag type indicator when moving to a different RRC state for a data transaction that is initiated by the UE or the network,
In some cases, the UE is only allowed for a predefined maximum number of transition indication messages in certain predefined states. The number may be different for different states. For example, the UE may only be allowed to transmit "n" transition indication messages (with or without the cause code as described above) when in the CELL_PCH or URA_PCH state of RRC.
In some modalities, methods and devices that comply with the Universal System of 20 Mobile Telecommunications (UMTS) of TS 25.331 of the 3GPP; Radio Resource Control (RRC); Protocol specification, Version 8, or an evolution thereof, with amendments to facilitate or implement one or more of the modalities described herein are provided. Examples of this 25 are provided in Appendix A, Appendix B and Appendix C. All of these examples refer to the use of SCRI, but more generally the use of any transition indication is contemplated.
In some embodiments (see Appendix A for an example implementation), a UE internal state variable is defined, which is set for the first time the UE fired an FD from the SHP state. If set, the UE is then prevented from firing an FD again from the PCH state, the variable is set when new PS data arrives for transmission.
In some embodiments (see Appendix B for an example implementation), a V316 counter is defined and initially set to zero. The UE in the PCH state is allowed to send a transition indication (such as a SCRI) with cause if V316 < N316 (N316 is the maximum value). If the UE does not trigger sending a transition indication (such as a SCRI with cause value) in the PCH state, then V316 will be incremented. V316 is reset to zero if the UE is radio called in the PCH state, or if the UE has uplink PS data available for transition.
If N316 is set to 1 then the behavior is equivalent to V316 being a boolean state variable. Note that the UE having PS data available for transmission specifically precludes sending a transition indication (such as a SCRI with cause) and causes counter V316 to be reset. In this context, the PS having data available can, for example, mean that the user has data to transmit on RB3 (radio carrier 3) or up (SCRI message is sent on RB2).
Note that the proposed text in 8.3.1.2 (cell update procedure) and the final paragraph of 8.1.14.2 are alternative ways to capture the condition for restarting V316.
In some embodiments (see Appendix C for an example implementation), the UE is prohibited from transmitting a transition indication (such as a SCRI with cause) if the network moves the UE to the PCH state in response to a transition indication (such as a SCRI with cause) 5 transmitted by the UE while in the DCH or FACE state. Prohibition of transition indication (such as a SCRI with cause) can be done by tuning from V316 to N316. The UE assesses whether the movement is instructed by the network 'in response' to the transition indication. The mechanisms 10 described previously can be used for this; for example, the UE may deem this to be the case if the reset is received within a certain time of sending the transition indication.
In some embodiments, a new flag type indicator 15 can be added to the reset message which can be set to TRUE if the reset message is triggered in the network upon receipt of a SCRI with cause, thus allowing the UE to know with sure the reconfiguration is in response to SCRI with 20 cause. An example of this is described in Appendix D.
Many different modalities for prohibiting the transmission of a transitional indication, completely or even some maximum number of transitional indications have been described. Many of these are a function of one or more 25 out of: whether the current state of the UE is the result of a previous state transition; if the current state is the same as the state of the UE before sending a state transition, if the current state is more battery-intensive than the state of the UE before sending a state transition.
In some modalities, a mechanism for prohibiting transmission of a transitional indication is implemented, or not, on a per-state basis; in some modalities, 5 for certain states, no mechanism is implemented. In other embodiments, a different mechanism is used for each of at least two states.
In one embodiment, the network has a plurality of choices on how to proceed when it has received an indication in step 1810 and, optionally, has examined the radio resource profile or profiles in step 1820.
A first option is to do nothing. The network may decide that a transition is not guaranteed and thus not accept user equipment indication to transition. As will be appreciated by those skilled in the art, doing nothing saves network signaling since the state is not changed and, in particular, since a transition is not triggered.
A second option is to change the device state. For example, in a UMTS network, the device state might change from Cell_DCH to Cell_PCH. In non-UMTS networks, state transition can occur between connected states. As will be appreciated by those skilled in the art, changing states reduces the amount of core network signaling as compared to a transition to an idle mode. Changing state can also save radio resources as the CELL_PCH state does not require a dedicated channel. Also, the CELL_PCH state is a less intensive state for the battery, allowing the UE 30 to preserve battery power.
A third option for the network is to keep the UE in the same state, but release the radio resources associated with a particular APN or PDP context. This approach saves radio and signaling resources as the connection is kept in its current state and does not need to be re-established. However, it may be less suitable for situations where EU battery life is a concern.
A fourth option for the network is to transition the UE to idle mode. In particular, in both UMTS and non-UMTS, the network can move from a connected mode to an idle mode. As will be appreciated, this saves radio resources as no connections are maintained at all. It also saves battery life on user equipment. However, a larger amount of core network signaling is required for connection re-establishment.
A fifth option for networking is to change a data rate allocation, which will save radio resources, typically allowing more users to use the network.
Other options would be evident to those skilled in the art. The network's decision on which of the five or more options to use will vary from network to network. Some overloaded networks may prefer to preserve radio resources 25 and so would choose the third, fourth, or fifth option above. Other networks prefer to minimize a beacon and so may choose the first or second option above.
The decision is shown in figure 18 at step 1830 and can be based on network preferences along with the radio resource profile for the user equipment. Decision II is triggered by the network upon receiving an indication from the user equipment that the user equipment would like to transition to another state, for example, to a less battery intensive state.
Reference is now made to Figure 19. Figure 19 illustrates the simplified network element adapted for making the decisions shown in Figure 18 above. Network element 1910 includes a communications subsystem 1920 adapted for communication with user equipment. As will be appreciated by those skilled in the art, the communications subsystem 1920 need not communicate directly with a user equipment, but could be part of a communications path for communications to and from the user equipment. 15. Network element 1910 further includes a processor 1930 and storage 1940. Storage 1940 is adapted to store pre-configured and static radio resource profiles for each user equipment being served by network element 1910. 1930 is adapted to, upon receipt of an indication by the 1920 communications subsystem, consider the radio resource profile for the user equipment and to decide on a network action with reference to a transition of the user equipment. As will be appreciated by those skilled in the art, the indication received by the 1920 communications subsystem could further include a portion or all of the radio resource profile for the user equipment which would then be used by the 1930 processor to make the decision. of 30 network concerning any transition.
Based on the above, a network element therefore receives an indication from the user equipment that a transition could be in order (such as, for example, when an exchange of data is completed and/or that no data 5 additional is expected in the UE) . Based on this indication, the network element optionally checks the radio resource profile of the user equipment, which could include static and dynamic profile elements. The network element can still check safeguards to ensure that unnecessary transitions are not taking place. The network element could then decide to do nothing, or transition to a different mode or state, or disconnect a radio resource. As will be appreciated, this gives the network more control of its radio resources and allows the network to . 15 configure transition decisions based on network preferences rather than merely user equipment preferences. Also, in some cases, the network element has more information than the device concerning the transition. For example, the user equipment has knowledge of counter-flow communications and, based on this, may decide that the connection can be dropped. However, the network may have received normal flow communications to the user equipment and thus have realized that it cannot break the connection. In this case, a delay can also be introduced using the delay timer to provide the network with more certainty that no data will be received for a user equipment in the near future.
The modalities described here are examples of 30 structures, systems or methods having elements corresponding to elements of the techniques in this exhibition. This written description may allow those skilled in the art to make and use modalities having alternative elements that likewise correspond to elements 5 of the techniques in this exhibition. The intended scope of the techniques of this exhibit thus includes other structures, systems or methods that do not differ from the techniques of this exhibit, as described herein, and further includes other structures, systems or methods with insubstantial differences from the techniques of this exhibit, as described here . Appendix A 8.1.14 Signaling Connection Release Indication Procedure
Figure 8.1.14-1: Signaling connection release indication procedure, normal case 8.1.14.1 General The signaling connection release indication procedure is used by the UE to indicate to the UTRAN which one of its connections signaling has been cleared, The procedure in turn can start the RRC connection release procedure. 8.1.14.2 Initiation The UE shall upon receiving a request to release (abort) the signaling connection from higher layers for a specific CN domain: 1> if a signaling connection in variable 5 ESTABLISHED JSIGNALLING_CONNECTIONS for the specific CN domain identified with IE "CN domain identity" exists: 2> start signaling connection release indication procedure. 10 1> otherwise: 2> abort any ongoing signaling connection establishment for that specific CN domain as specified in 8.1.3.5a. Upon initiation of the indication procedure of 15. signaling connection release in state in CELLJPCH or URA_PCH, the UE must: 1> if variable READY_FOR_COMMON_EDCH is set to TRUE: 2> move to state CELL_FACH; 2 0 2> restart timer T305 using its initial value if a periodic cell update has been configured by T305 in IE "UE timers and constants in connected mode" set to any value other than "infinite". 25 1> if not: 2> if variable H_RNTI and variable C_RNTI are set: 3> continue with signaling connection release indication procedure as below. 30 2> if not: 3> perform a cell update procedure, according to subitem 8.3.1, using the cause "uplink data transmission";3> when the cell update procedure has 5 completed successfully: 4> continue with the signaling connection release indication procedure as below. The UE must: 1> set the IE "DN Domain Identity" to the value indicated by the upper layers. The IE value indicates the CN domain whose associated signaling connection the upper layers are indicating to be released; 1> remove signaling connection with identity. 15 indicated by the upper layers of the variable ESTAB LISHED_SIGNALLING_CONNECTIONS; 1> transmit a SIGNALING CONNECTION RELEASE INDICATION message on DCCH using AM RLC.
When successful delivery of the message 20 SIGNALING CONNECTION RELEASE message has been confirmed by the RLC, the procedure ends.
Also, if timer value T323 is stored in IE "UE timers and constants in connected mode" in variable TIMERS_AND_CONSTANTS, and if there is no CS domain connection indicated in variable ESTABLISHED_SIGNALLING_CONNECTIONS, UE can: 1> se upper layers indicate no more PS data for an extended period: 2> if timer T323 is not running: 30 3> if UE is in CELL_DCH state or CELL_FACH state; or 3> if the UE is in the CELL_PCH state or in the URA_PCH state and "Triggered" in the TRIGGERED_SCRI_IN_PCH_STATE variable is FALSE: 5 4> if the UE is not in the CELL__PCH or URA_PCH state, set "Triggered" in the TRIGGERED_SCRI_IN_PCH_STATE variable to VERIFY; 4> set IE "CN Domain Identity" for PS domain; 10 4> set IE "Signaling Connection Release Indication Cause" to "UE Requested PS Data logout"; 4> transmit a SIGNALING CONNECTION RELEASE INDICATION message on DCCH using AM RLC; 15 4> start timer T323.
When the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been confirmed by the RLC, the procedure ends.
The UE should be prevented from sending the SIGNALING CONNECTION RELEASE INDICATION 20 message with the IE "Signaling Connection Release Indication Cause" set to "UE Requested PS Data Logoff" while timer T323 is running .
After sending the SIGNALING CONNECTION RELEASE INDICATION message with the IE "Signaling Connection Release Indication Cause" set to "UE Requested PS Data logout", if the PS data becomes available to transmission, then the UE must set "triggered" in the TRIGGERED_SCRI_IN_PCH_STATE variable 30 to FALSE. 8.1.14.2a RLC reset or inter-RAT change If a reset of the transmit side of the RLC entity in the signaling of the radio bearer RB2 occurs before the successful delivery of the message SIGNALING CONNECTION RELEASE INDICATION 5 has been acknowledged by RLC, the UE shall: 1> retransmit the SIGNALING CONNECTION RELEASE INDICATION message on the uplink DCCH using AM RLC on signaling radio bearer RB2, 10 If a point-to-point Inter-RAT transfer from a procedure of UTRAN occurs before the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been acknowledged by the RLC, the UE must: 1> abort the signaling connection while in the new 15 • RAT 8.1.14.3 Reception of CONNECTION RELEASE INDICATION SIGNALING BY UTRAN Upon receipt of a SIGNALING CONNECTION RELEASE INDICATION message, if the IE "Cause of 20 Signaling Connection Release Indication" is not has included, the UTRAN will request the release of the signaling connection from the upper layers. The upper layers can then initiate the release of the signaling connection. 25 If the IE "Signaling Connection Release Indication Cause" is included in the SIGNALING CONNECTION RELEASE INDICATION message, the UTRAN may initiate a state transition to an efficient battery drain INACTIVE, a CELL_PCH, URA_PCH or 3 state 0 CELL_FACH. II 8.1.14.4 Timer T323 Expiration When timer T323 expires: 1> the UE can determine if any subsequent indications from higher layers that there is no more PS data for an extended period, in which case it triggers the transmission of a single message INDICATION OF SIGNALING CONNECTION RELEASE in accordance with item 8.1.14.2; 1> the procedure ends. 13.4.27x TRIGGERED_SCRI_IN_PCH_STATE
This variable contains information as to whether a SIGNALING CONNECTION RELEASE INDICATION message was triggered in CELL_PCH or URA_PCH states. There is a variable like that in the UE.
Appendix B 8.1.14 Signaling Connection Release Indication Procedure
Figure 8.1.14-1: Signaling connection release indication procedure, normal case 8.1.14.1 General The signaling connection release indication procedure is used by the UE to indicate to the UTRAN which one of its signaling connections has been released. The procedure in turn can start the RRC connection release procedure. 8.1.14.2 Initiation 10 The UE shall upon receiving a request to release (abort) the signaling connection from higher layers for a specific CN domain: 1> if a signaling connection in the variable ESTABLISHED_SIGNALLING_CONNECTIONS for the CN domain * 15 specific identified with IE "CN domain identity" exists: 2> start signaling connection release indication procedure. 1> otherwise: 20 2> abort any ongoing signaling connection establishment for that specific CN domain as specified in 8.1.3.5a. Upon initiation of signaling connection release indication procedure in state in CELL_PCH 25 or URAJPCH, the UE must: 1> if variable READY_FOR_COMMON_EDCH is set to TRUE: 2> move to state CELL_FACH; 2> restart timer T305 using its initial value 30 if a periodic cell update has been configured by T305 in IE "UE timers and constants in connected mode" set to any value other than "infinite". 1> if not: 2> if variable H_RNTI and variable C_RNTI are set: 3> continue with signaling connection release indication procedure as below. 2> if not: 3> perform a cell update procedure, according to subitem 8.3.1, using the cause "uplink data transmission";3> when cell update procedure completed successfully: 4> continue with signaling connection release indication procedure as below. The UE must: 1> set the IE "DN Domain Identity" to the value indicated by the upper layers. The IE value indicates the CN domain whose associated signaling connection the upper layers are indicating to be released; 1> remove the signaling connection with the identity indicated by the upper layers of the variable ESTABLISHED_SIGNALLING_CONNECTIONS; 1> transmit a SIGNALING CONNECTION RELEASE INDICATION message on DCCH using AM RLC.
When the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been confirmed by the RLC, the procedure ends.
Also, if timer value T323 is stored in IE "UE timers and constants in connected mode" in variable TIMERS_AND_CONSTANTS, and if there is no CS domain connection indicated in variable 5 ESTABLISHED_SIGNALLING_CONNECTIONS, UE can: 1> se the upper layers indicate that there is no more PS data for an extended period: 2> if timer T323 is not running: 3> if UE is in CELL_DCH state or in CELL_FACH state 10; or 3> if UE is in CELL_PCH state or URA_PCH state and V316 < N316: 4> if UE is not in CELL_PCH or URA_PCH state, increment V316 by 1; 1-5 4> set IE "CN Domain Identity" for PS domain; 4> set IE "Signaling Connection Release Indication Cause" to "UE Requested PS Data Logout"; 20 4> transmit a SIGNALING CONNECTION RELEASE INDICATION message on DCCH using AM RLC; 4> Start timer T323.
When the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been confirmed by the RLC, the procedure ends.
The UE should be prevented from sending the SIGNALING CONNECTION RELEASE INDICATION message with the IE "Signaling Connection Release Indication Cause" set to "UE Requested PS Data Logoff" while timer T323 is running .
If PS data becomes available for transmission or the UE receives a radio call message that triggers a cell update procedure, then the UE should set V316 to zero. 8.1.14.2a RLC Reset or Inter-RAT Switch If a reset of the transmit side of the RLC entity in the signaling of the radio bearer RB2 occurs before the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been confirmed by the RLC, the UE shall: 1> retransmit the SIGNALING CONNECTION RELEASE INDICATION message on the uplink DCCH using AM RLC on signaling radio bearer RB2. If a 15' Inter-RAT point-to-point transfer from an UTRAN procedure occurs before handover, the successful SIGNALING CONNECTION RELEASE INDICATION message has been acknowledged by the RLC, the UE shall: 1> abort the connection signaling while in the new RAT 20 8.1.14.3 Reception of SIGNALING CONNECTION RELEASE INDICATION by the UTRAN Upon receipt of a SIGNALING CONNECTION RELEASE INDICATION message, if the IE "Cause of Signaling Connection Release Indication" does not 25 is included, the UTRAN will request the release of the signaling connection from the upper layers. The upper layers can then initiate the release of the signaling connection. If the IE "Signal Connection Release Indication Cause" is included in the SIGNALING CONNECTION RELEASE INDICATION message, the UTRAN may initiate a state transition to an efficient battery consumption INACTIVE, a CELL_PCH, URA_PCH or CELL_FACH state . 5 8.1.14.4 Timer T323 Expiration When timer T323 expires: 1> the UE can determine if any subsequent indications from higher layers that there is no more PS data for an extended period, in which case it triggers the transmission of a single message SIGNALING CONNECTION RELEASE INDICATION message in accordance with item 8.1.14.2; 1> the procedure ends. 8.3 RRC Connection Mobility Procedures 8.3.1 Cell and IVR Update Procedures




The URA update and cell update procedures serve many main purposes: to notify the UTRAN after re-entering a service area in the state of URA_PCH or CELL_PCH; notify the UTRAN of an RLC unrecoverable error [16] in an AM RLC entity; be used as a supervisory mechanism in the CELL_FACH, CELL_PCH, or URA_PCH state through a periodic update.
In addition, the URA update procedure also serves the following purpose: retrieving a new URA identity after a cell reselection for a cell not belonging to the current URA assigned to the UE in the URA_PCH state.
In addition, the cell update procedure also serves the following purposes: updating the UTRAN with the current cell the UE is camping in after a cell reselection; act on a radio link failure in CELL_DCH state; act on the failure to transmit the EU CAPACITY INFORMATION message; for FDD and TDD of 1.28 Mcps, if the variable H_RNTI is not regulated, and for TDD of 2.84 Mcps and TDD of 7.68 Mcps:
When triggered in the URA_PCH or CELL_PCH state, notifying the UTRAN of a transition to the CELL_FACH state due to reception of a radio call originating in UTRAN or due to a request for uplink data transmission; count the number of UEs in URA_PCH, CELL_PCH and CELL_FACH that are interested in receiving an MBMS transmission; when triggered in URA_PCH, CELL_PCH and CELL_FACH state, notifying the UTRAN of the interest of the UE in receiving an MBMS service; request from the MBMS the establishment of P-T-P RB by the UE in the state CELL_PCH, URA_PCH and CELL_FACH.
The URA update and cell update procedures can: 1> include information related to mobility update in the UE; 1> cause a state transition from CELL_FACH state to CELLJDCH, CELL_PCH or URA_PCH states or idle mode.
The cell update procedure may also include: a re-establishment of AM RLC entities; a radio bearer reset, a radio bearer reset, a transport channel reset, or a physical channel reset, 8.3.1.2 Initiation
A UE must start the cell update procedure in the following cases: 1> Uplink data transmission: 2> for FDD and TDD of 1.28 Mcps, if the variable H_RNTI is not regulated, and for TDD of 2, 84 Mcps and TDD of 7.68 Mcps: 3> if UE is in URA_PCH or CELL_PCH state; and 3> if timer T320 is not running: 4> if the UE has an uplink RLC data PDU or an uplink RLC control PDU on RB1 or up to transmit: 5> perform an update of cell using the cause "uplink data transmission". 3> else: 4> if variable ESTABLISHMENT_CAUSE is set: 5> perform a cell update using the cause "uplink data transmission". 1> Radio call response: 2> if the criteria for performing the cell update with the cause specified above in the current sub-item is not met; and 2> if the UE in the URA_PCH or CELL_PCH state receives a RADIO CALL TYPE 1 message meeting the conditions for initiating a cell update procedure in subitem 8.1,2.3; 3> perform a cell update using the "radio call response" cause. 1> Radio link failure: 2> if none of the criteria for performing a cell update with the causes specified above is met: 3> if the UE is in the CELL_DCH state and the radio link failure criteria are met as per specified in subsection 8.5.6; or 3> if the transmission of the UE CAPACITY INFORMATION message fails as specified in subitem 8.1.6.6: 4> perform a cell update using the "radio link failure" cause. 1> MBMS ptp RB request: 2> if none of the criteria for carrying out a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the URA_PCH, Cell_PCH or CellJFACH state; and 2> if timer T320 is not running; and 10 2> if the UE has to perform a cell update for an MBMS ptp radio bearer request as specified in subitem 8.6.9.6: 3> perform a cell update using the cause "MBMS ptp RB request" . 15 1> Re-entry into the service area: 2> if none of the criteria for carrying out a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the CELL_FACH or CELL_PCH state; 20 and 2> if the UE has been out of service area and re-enters the service area before T307 or T317 expires: 3> perform a cell update using the "Service area re-entry" cause. 25 1> RLC unrecoverable error: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE detects an RLC unrecoverable error 30 [16] in an AM RLC entity: 3> perform a cell update using the cause "RLC unrecoverable error". 1> Cell reselection: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met: 3> if the UE is in the CELL_FACH or CELL_PCH state and the UE performs a cell reselection ; or 3> if the UE is in the CELL_FACH state and the C_RNTI variable is empty: 4> perform a cell update using the cause "cell reselect". 1> Periodic cell update: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the CELL_FACH or CELL_PCH state; and 2> if timer T305 expires; and 2> if the criteria for "in service area" as specified in sub-item 8.5.5.2 are met; and 2> if a periodic update has been configured by T305 in IE "UE timers and constants in connected mode" set to any value other than "infinite": 3> for FDD: 4> if variable COMMON_E_DCH_TRANSMISSION is set to FALSE : 5> perform a cell update using the cause
"Periodic cell update". 4> if not: 5> restart timer T305; 5> and end of procedure, 3> for TDD of 1.28 Mcps and 3.84/TDD of 7.68 Mcps: 4> perform a cell update using the cause "Periodic cell update". 1> receiving MBMS: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the URA_PCH, Cell_PCH or Cell_FACH state; and 2> if the UE has to perform a cell update for MBMS count as specified in sub-item 8.7.4: 3> perform a cell update using the cause "MBMS reception".
A UE in the URA_PCH state must start the URA update procedure in the following cases: 1> URA reselection: 2> if the UE detects that the current URA assigned to the UE, stored in the URA_IDENTITY variable, is not present in the list of identities of URA in the type 2 system information block; or 2> if the list of IVR identities in the type 2 system information block is empty; or 2> if the type 2 system information block cannot be found: 3> perform an IVR update using the cause 1> Periodic IVR update: 2> if the criteria for performing an IVR update with the causes as specified above in the current subitem are not met: 3> if timer T305 expires and if a periodic update has been configured by T3 05 in IE "UE timers and constants in connected mode" set to any other value than "infinite "; or 3> if the conditions for initiating an IVR update procedure specified in sub-item 8.1.1.6.5 are met: 4> perform an IVR update using the cause "IVR periodic update".
When initiating the URA update procedure or cell update procedure, the UE shall: 1> if the UE has the uplink RLC data PDU or the uplink RLC control PDU in THIRD EDGE or up to transmit; or 1> if the UE received a TYPE 1 RADIO CALL message meeting the conditions for initiating a cell update procedure specified in sub-item 8.1.2.3: 2> set counter V316 to zero. 1> if timer T320 is running: 2> stop timer T320; 2> if the UE has an uplink RLC data PDU or an uplink RLC control PDU in RB1 or up to transmit: 3> perform a cell update using the cause "uplink data transmission ". 2> if not: 3> if cell update procedure is not triggered due to Radio Call Answer or Radio Link Failure; and 3> if the UE has to perform a cell update for an MBMS ptp radio bearer request as specified in subitem 8.6.9.6: 4> perform a cell update using the cause "MBMS ptp RB request". 1> stop timer T319 if it is running; 1> stop timer T305; 1> for FDD and TDD of 1.28 Mcps: 2> if UE is in CELL_FACH state; and 2> if the IE "HS-DSCH common system information" is included in the type 5 system information block or type 5bis System Information Block; and 2> for TDD of 1.28 Mcps, if the IE "Common E-DCH System Information" in the type 5 system information block; and 2> if the UE does not support an HS-DSCH reception in the CELL_FACH state: 3> if the H_RNTI variable is not set or the C_RNT1 variable is not set: 4> clear the H_RNTI variable; 4> clear the C_RNTI variable; 4> clear any IEs stored "HARQ information"; 4> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 4> and begin to receive the physical channels mapped from HS-DSCH transport channels of type HS-SCCH and HS-PDSCH, by using parameters given by the IE(s) "HS-DSCH common system information" according to the procedure in subitem 8.5.37. 3> if not: 4> receive the physical channels mapped from HS-DSCH transport channels of type HS-SCCH and HS-PDSCH, by the use of parameters given by the IE(s) "HS-DSCH common system information " in accordance with the procedure in subitem 8.5.36; 4> determine the value for the variable HSPA_RNTI_STORED_CELL_PCH and take the corresponding measures as described in subitem 8.5.56; 4> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 4> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46; 4> if variable READY_FOR_COMMON_EDCH is set to TRUE: 5> configure Enhanced Uplink in CELL_FACH state and in idle mode as specified in subitem 8.5.45 for FDD and 8.5.45a for TDD of 1.28 Mcps. 1> if the UE is in CELL_DCH state: 2> in the RB_TIMER_INDICATOR variable, set the IE "T314 expired" and the IE "T315 expired" to FALSE; 2> if the stored values of timer T314 and timer T315 are both equal to zero; or 2> if the stored value of timer T314 is equal to zero and there are no radio carriers associated with any radio access carriers for which in the variable ESTABLISHED_RABS the value of the IE "Timer Reset" is set to "useT315" and a signaling connection exists only in the CS domain: 3> release all its radio resources; 3> indicate to release (abort) established signaling connections (as stored in ESTABLISHED_SIGNALLING_CONNECTIONS variable) and established radio access bearers (as stored in ESTABLISHED_RABS variable) to higher layers; 3> clear the ESTABLISHED_SIGNALLING_CONNECTIONS variable; 3> clear the ESTABLISHED_RABS variable; 3> enter idle mode; 3> perform other actions when entering idle mode from connected mode, as specified in sub-item 8.5.2; 3> and the procedure ends. 2> if the stored value of timer T314 is equal to zero: 3> release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to " useT314"; 3> in the variable RB_TIMER_INDICATOR set the IE "T314 expired" to TRUE; 3> if all radio access bearers associated with a CN domain are released: 4> release the signaling connection for that CN 4> remove the signaling connection for that CN domain from the ESTABLISHED_SIGNALLING_CONNECTIONS variable; 4> indicate to release (abort) the signaling connection to higher layers; 2> if the stored value of timer T315 is equal to zero: 3> release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT315 "; 3> in the variable RB_TIMER_INDICATOR set the IE "T315 expired" to TRUE. 3> if all radio access bearers associated with a CN domain are released: 4> release the signaling connection for that CN domain; 4> remove the signaling connection for that CN domain from the ESTABLISHED_SIGNALLING_CONNECTIONS variable; 4> indicate to release (abort) the signaling connection to higher layers; 2> if the stored value of timer T314 is greater than zero: 3> if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT314 ": 4> start timer T314. 3> if there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT314" or "useT315" and the signaling connection exists for the domain of CS: 4> start timer T314. 2> if the stored value of timer T315 is greater than zero: 3> if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT315 "; or 3> if signaling connection exists for PS domain: 4> start timer T315. 2> for the released radio bearer(s): 3> erase the information about the radio bearer from the variable ESTABLISHED_RABS; 3> when all radio bearers belonging to the same radio access bearer have been released: 4> indicate local end release of the radio access bearer to higher layers using the domain identity of CN together with the identity of RAB stored in the variable ESTABLISHED_RABS; 4> delete all information about the radio access bearer from the variable ESTABLISHED_RABS. 2> if the E_DCH_TRANSMISSION variable is set to TRUE: 3> set the E_DCH_TRANSMISSION variable to FALSE; 3> stop any E-AGCH and E-HICH receiving procedures; 3> for FDD, stop any E-RGCH receiving procedures. 3> for FDD, stop any E-DPCCH and E-DPDCH transmission procedures. 3> for 1.28 Mcps TDD, stop any E-PUCH transmission procedure. 3> clear the E_RNTI variable; 3> act as if the IE "reset MAC-es/e indicator" had been received and was set to TRUE; 3> release all HARQ resources of E-DCH; 3> no longer consider any radio link to be the service E-DCH radio link. 2> move to CELL_FACH state; 2> select a suitable UTRA cell at the current frequency according to [4]; 2> clear the variable E 1_RNTI and: 3> determine the value for the variable HSPA_RNTI _STORED_CELL_PCH and take the corresponding measures as described in subitem 8.5. 56; 3> determine the value for the variable READY_FOR _COMMON_EDCH and take the corresponding measures as described in sub-item 8.5.47 r 3> determine the value for the variable COMMON E_DCH TRANSMISSION and take the corresponding measures as described in sub-item 8.5.46. 2> for TDD of 2.84 Mcps and TDD of 7.68 Mcps; or 2> for FDD and TDD of 1.28 Mcps, if the UE does not support an HS-DSCH reception in the CELL FACH state; or 2> if the IE "HS-DSCH common system information" is not included in the type 5 system information block or the type 5bis System Information Block; or 2> for TDD of 1.28 Mcps, if IE "Common E-DCH System Information" is not included in Type 5 System Information Block: 3> Select PRACH according to subitem 8.5.17; 3> select Secondary CCPCH according to subitem 8.5.19; 3> use the transport format setting given in the system information as specified in subitem 8.6.5.1 ; 3> take the measures related to the variable HS_DSCH_RECEPTION_GENERAL as described in subitem 8.5.37a. 2> if not: 3> if variable READY_FOR_COMMON_EDCH is set to TRUE: 4> configure Enhanced Uplink in CELL_FACH state and in idle mode as specified in subitem 8.5.45. 3> if not: 4> select PRACH according to subitem 8.5.17 and: 5> use for the PRACH the transport format setting given in the system information as specified in subitem 8.6.5.1. 3> clear the H_RNTI variable; 3> clear any IEs stored "HARQ information"; 3> reset the MAC-ehs entity [15]; 3> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 3> and start receiving the HS-DSCH according to the procedure in subitem 8.5.37. 2> set the ORDEREDJRECONFIGURATION variable to FALSE. 1> set the PROTOCOL_ERROR_INDICATOR, FAILURE_INDICATOR, UNSUPPORTED_CONFIGURATION and INVALID_CONFIGURATION variables to FALSE; 1> set the CELL_UPDATE_STARTED variable to TRUE; 1> if any HS-DSCHAre related IES stored in the UE: 2> clear any stored IE "Downlink HS-PDSCH Information"; 2> clear any stored IE "Downlink Secondary Cell Information FDD"; 2> clear all entries for the TARGET_CELL_PRECONFIGURATION variable; 2> for TDD of 1.28 Mcps, clear IE "Intermediate Block Configuration of HS-PDSCH" and IE "Regular Configuration of HS-SCCH" in IE "Multi-Carrier DL Information"; 2> determine the value for the variable HS_DSCH_RECEPTION and take the corresponding measures as described in subitem 8.5.25; 2> determine the value for the variable SECONDARY_CELL_HS_DSCH_RECEPTION and take the corresponding measures as described in subitem 8.5.51, 1> if any IEs related to E-DCH are stored in the UE: 2> clear any IE stored "E-DCH information" ; 2> determine the value for the variable E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.28. 1> if any of the IEs "DTX-DRX Sync Information" or "DTX-DRX Information" is stored in the UE: 2> determine the value for the variable DTX_DRX_STATUS and take the corresponding measures as described in subitem 8.5.34 . 1> if the IE "Information less than HS-SCCH" is stored in the UE: 2> determine the value for the variable HS_SCCH_LESS_STATUS and take the corresponding measures as described in subitem 8.5.35. 1> if any MIMO-related IEs are stored in the UE: 2> determine the value for the variable MIMO_STATUS and take the corresponding measures as described in subitem 8.5.33. 1> for TDD of 1.28 Mcps, if the IEs "Control Channel DRX Information" is stored in the UE: 2> determine the value for the variable CONTROL_CHANNELJDRX_STATUS and take the corresponding measures as described in subitem 8.5.53. 1> for TDD of 1.28 Mcps, if the IE "SPS Information" is stored in the UE: 2> determine the value for the variable E_DCH_SPS_STATUS and take the corresponding measures as described in subitem 8.5.54; 2> determine the value for the variable HS_DSCH_SPS_STATUS and take the corresponding measures as described in subitem 8.5.55. 1> if the UE is not yet in CELL_FACH state: 2> move to CELL_FACH state; 2> determine the value for the variable HSPA RNTI STORED CELL PCH and take the corresponding measures as described in subitem 8.5.56; 2> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 2> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46; 2> for TDD of 2.84 Mcps and TDD of 7.68 Mcps; or 2> for FDD and TDD of 1.28 Mcps, if the UE does not support an HS-DSCH reception in the CELL_FACH state; or 2> if the IE "HS-DSCH common system information" is not included in the type 5 system information block or type 5bis System Information Block; or 2> for TDD of 1.28 Mcps, if IE "Common E-DCH System Information" is not included in Type 5 System Information Block: 3> Select PRACH according to subitem 8.5.17; 3> select Secondary CCPCH according to subitem 8.5.19; 3> use the transport format setting given in the system information as specified in subitem 8.6.5.1 ; 3> take the measures related to the variable HS_DSCH_RECEPTION_GENERAL as described in subitem 8.5.37a. 2> if not: 3> if variable READY_FOR_COMMON_EDCH is set to TRUE: 4> configure Enhanced Uplink in CELL_FACH state and in idle mode as specified in subitem 8.5.45. 3 > if not: 4> select PRACH according to subitem 8.5.17 and: 5> use for the PRACH the transport format setting given in the system information as specified in subitem 8.6.5.1. 3> if variable H_RNTI is not set or variable C_RNT1 is not set: 4> clear variable C_RNTI; 4> clear the H_RNTI variable; 4> clear any IEs stored "HARQ information"; 4> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 4> and start receiving the HS-DSCH according to the procedure in subitem 8.5.37. 3> if not: 4> receive the HS-DSCH according to the procedure in subitem 8.5.36. 1> if the UE performs a cell reselection: 2> clear the C_RNTI variable; and 2> stop using that C_RNTI just cleared from the C_RNTI variable in MAC; 2> for FDD and TDD of 1.28 Mcps, if variable H_RNTI is set: 3> clear variable H_RNTI; and 3> stop using that newly cleared H_RNTI from the H_RNTI variable in MAC; 3> clear any IEs stored "HARQ information"; 2> for FDD and TDD of 1.28 Mcps, if variable E_RNTI is set: 3> clear variable E_RNTI. 2> determine the value for the variable HSPA_RNTI_STORED_CELL_PCH and take the corresponding measures as described in subitem 8.5.56; 2> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 2> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46; 2> for 1.28 Mcps FDD and TDD, if the UE does not support an HS-DSCH reception in the CELL_FACH state and the IE "HS-DSCH common system information" is included in the type 5 system information block or System Information Block of type 5bis: 3> reset the MAC-ehs entity [15]. 3> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 3> and start receiving the HS-DSCH according to the procedure in subitem 8.5.37. 2> if not: 3> take the measures related to the variable HS_DSCH_RECEPTION_GENERAL as described in subitem 8.5.37a. 1> regulate CFN in relation to current cell SFN according to subitem 8.5.15; 1> in case of a cell update procedure: 2> regulate the content of the CELL UPDATE message according to sub-item 8.3.1.3; 2> submit the CELL UPDATE message for transmission on the uplink CCCH. 1> in the case of an IVR Update Procedure: 2> regulate the content of the IVR UPDATE message according to sub-item 8.3.1.3; 2> submit the URA UPDATE message for transmission on the uplink CCCH. 1> set counter V302 to 1; 1> Start timer T302 when MAC layer indicates message transmission success or failure. 10.3.3.43 UE and Constant Timers in Connected Mode
This information element specifies timer values and constants used by the UE in connected mode.






13.4.27x TRIGGERED_SCRI_IN_PCH_STATE
This variable contains information as to whether a SIGNALING CONNECTION RELEASE INDICATION message was triggered in CELL_PCH or URA_PCH states. There is a 5 variable like this in the UE.
13.2 Counters for EU




The signaling connection release indication procedure is used by the UE to indicate to the UTRAN that one of its signaling connections has been released. The procedure in turn can start the RRC connection release procedure. 8.1.14.2 Initiation
The UE must upon receiving a request to release (abort) the signaling connection from higher layers for a specific CN domain: 1> if a signaling connection in the variable ESTABLISHED_SIGNALLING_CONNECTIONS for the specific CN domain identified with the IE "identity domain name" exists: 2> start signaling connection release indication procedure. 1> otherwise: 2> abort any ongoing signaling connection establishment for that specific CN domain as specified in 8.1.3.5a.
Upon initiation of signaling connection release indication procedure in state in CELL_PCH or URA_PCH, the UE must: 1> if variable READY_FOR_COMMON_EDCH is set to TRUE: 2> move to state CELL_FACH; 2> restart timer T305 using its initial value if a periodic cell update has been configured by T305 in IE "UE timers and constants in connected mode" set to any value other than "infinite". 1> if not: 2> if variable H_RNTI and variable C_RNTI are set: 3> continue with signaling connection release indication procedure as below. 2> if not: 3> perform a cell update procedure, according to subitem 8.3.1, using the cause "uplink data transmission"; 3> when cell update procedure completed successfully: 4> continue with signaling connection release indication procedure as below. The UE must: 1> set the IE "DN Domain Identity" to the value indicated by the upper layers. The IE value indicates the CN domain whose associated signaling connection the upper layers are indicating to be released; 1> remove the signaling connection with the identity indicated by the upper layers of the variable ESTABLISHED_SIGNALLING_CONNECTIONS; 1> transmit a SIGNALING CONNECTION RELEASE INDICATION message on DCCH using AM RLC.
When the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been confirmed by the RLC, the procedure ends.
Also, if timer value T323 is stored in IE "UE timers and constants in connected mode" in variable TIMERS_AND CONSTANTS, and if there is no CS domain connection indicated in variable ESTABLISHED_SIGNALLING_CONNECTIONS, the UE can: 1> se upper layers indicate that there is no more PS data for an extended period: 2> if timer T323 is not running: 3> if UE is in CELL_DCH state or CELL_FACH state; or 3> if UE is in CELL_PCH state or URA_PCH state and V316 < N316: 4> if UE is not in CELL_PCH or URA_PCH state, increment V316 by 1; 4> set IE "CN Domain Identity" for PS domain; 4> set IE "Signaling Connection Release Indication Cause" to "UE Requested PS Data Logout"; 4> transmit a SIGNALING CONNECTION RELEASE INDICATION message on DCCH using AM RLC; 4> Start timer T323.
When the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been confirmed by the RLC, the procedure ends.
The UE should be prevented from sending the SIGNALING CONNECTION RELEASE INDICATION message with the IE "Signaling Connection Release Indication Cause" set to "UE Requested PS Data session end" while timer T323 is running.
If PS data becomes available for transmission or the UE receives a radio call message that triggers a cell update procedure, then the UE shall V316 stop. zero.
If the UE sends the SIGNALING CONNECTION RELEASE INDICATION message with the IE "Signaling Connection Release Indication Cause" set to "UE Requested end of PS Data session" in CELL_DCH or CELL_FACH state, and in response when UE receives a reconfiguration message that makes the UE transition to CELL_PCH or URA_PCH state, then the UE must set V316 to N316. The UE shall consider the reset message to be in response to the SIGNALING CONNECTION RELEASE INDICATION message, if it is received within 500 ms. 8.1.14.2a RLC Reset or Inter-RAT Change
If a reset of the transmit side of the RLC entity in the signaling of the radio bearer RB2 occurs before the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been acknowledged by the RLC, the UE shall: 1> retransmit the INDICATION OF message SIGNALING CONNECTION RELEASE on uplink DCCH using AM RLC on signaling radio bearer RB2. If an Inter-RAT point-to-point transfer from an UTRAN procedure occurs before the successful delivery of the SIGNALING CONNECTION RELEASE INDICATION message has been acknowledged by the RLC, the UE shall: 1> abort the signaling connection while in the new RAT 8.1.14.3 Reception of SIGNALING CONNECTION RELEASE INDICATION by UTRAN
Upon receipt of a SIGNALING CONNECTION RELEASE INDICATION message, if the IE "Signaling Connection Release Indication Cause" is not included, the UTRAN will request the release of the signaling connection from the upper layers. The upper layers can then initiate the release of the signaling connection.
If the IE "Signaling Connection Release Indication Cause" is included in the SIGNALING CONNECTION RELEASE INDICATION message, the UTRAN may initiate a state transition to an efficient battery consumption INACTIVE, a CELL_PCH, URA_PCH or CELL_FACH state. 8.1.14.4 Timer T323 Expiration When timer T323 expires: 1> the UE can determine if any subsequent indications from higher layers that there is no more PS data for an extended period, in which case it triggers the transmission of a single message SIGNALING CONNECTION RELEASE INDICATION message in accordance with item 8.1.14.2; 1> the procedure ends. 8.3 RRC Connection Mobility Procedures 8.3.1 Cell and IVR Update Procedures



Figure 8.3.1-10: IVR update procedure, in case of failure 8.3.1.1 General ages
The URA update and cell update procedures serve many main purposes: to notify the UTRAN after re-entering a service area in the state of URA_PCH or CELL_PCH; notify the UTRAN of an RLC unrecoverable error [16] in an AM RLC entity; be used as a supervisory mechanism in the CELL_FACH, CELL_PCH, or URA_PCH state through a periodic update.
In addition, the URA update procedure also serves the following purpose: retrieving a new URA identity after a cell reselection for a cell not belonging to the current URA assigned to the UE in the URA_PCH state.
In addition, the cell update procedure also serves the following purposes: updating the UTRAN with the current cell the UE is camping in after a cell reselection; - act on a radio link failure in CELL_DCH state; act on the failure to transmit the EU CAPACITY INFORMATION message; for FDD and TDD of 1.28 Mcps, if the variable H_RNTI is not regulated, and for TDD of 2.84 Mcps and TDD of 7.68 Mcps:
When triggered in the URA PCH or CELL PCH state, notifying the UTRAN of a transition to the CELL_FACH state due to reception of a radio call originating in UTRAN or due to a request for uplink data transmission; 5 - counting the number of UEs in URA_PCH, CELL_PCH and CELL_FACH that are interested in receiving an MBMS transmission; when triggered in URA_PCH, CELL_PCH and CELL_FACH state, notifying the UTRAN of the interest of the UE in receiving an MBMS service; request from the MBMS the establishment of P-T-P RB by the UE in the state CELL_PCH, URA_PCH and CELL_FACH.
The URA update and cell update procedures can: 1> include information related to mobility update in the UE; 1> cause a state transition from CELL_FACH state to CELLJDCH, CELL_PCH or URA_PCH states or idle mode.
The cell update procedure may also include: a re-establishment of AM RLC entities; a radio bearer reset, a radio bearer reset, a transport channel reset, or a physical channel reset. 8.3.1.2 Initiation
A UE must start the cell update procedure in the following cases: 1> Uplink data transmission: 2> for FDD and TDD of 1.28 Mcps, if the variable H_RNTI is not regulated, and for TDD of 2, 84 Mcps and TDD of 7.68 Mcps: 3> if UE is in URA_PCH or CELL_PCH state; and 3> if timer T320 is not running: 4> if the UE has an uplink RLC data PDU or an uplink RLC control PDU on RB1 or up to transmit: 5> perform an update of cell using the cause "uplink data transmission". 3 > if not: 4> if variable ESTABLISHMENT_CAUSE is set: 5> perform a cell update using the cause "uplink data transmission". 1> Radio call response: 2> if the criteria for performing the cell update with the cause specified above in the current sub-item is not met; and 2> if the UE in the URA_PCH or CELL_PCH state receives a RADIO CALL TYPE 1 message meeting the conditions for initiating a cell update procedure in subitem 8.1,2.3: 3> perform a cell update using the cause " radio call response". 1> Radio link failure: 2> if none of the criteria for performing a cell update with the causes specified above is met: 3> if the UE is in the CELL_DCH state and the radio link failure criteria are met as per specified in subsection 8.5.6; or 3> if the transmission of the UE CAPACITY INFORMATION message fails as specified in subitem 8.1.6.6: 4> perform a cell update using the "radio link failure" cause. 1> MBMS ptp RB request: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the URA_PCH, Cell_PCH or Cell_FACH state; and 2> if timer T320 is not running; and 2> if the UE has to perform a cell update for an MBMS ptp radio bearer request as specified in subitem 8.6.9.6: 3> perform a cell update using the cause "MBMS ptp RB request". 1> Re-entry into the service area: 2> if none of the criteria for carrying out a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the CELL_FACH or CELL_PCH state; and 2> if the UE has been out of service area and re-enters the service area before T307 or T317 expires; 3> perform a cell update using the "Service area re-entry" cause. 1> RLC unrecoverable error: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE detects an RLC unrecoverable error [16] in an AM RLC entity: 3> perform a cell update using the cause "RLC unrecoverable error". 1> Cell reselection: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met: 3> if the UE is in the CELL_FACH or CELL_PCH state and the UE performs a cell reselection ; or 3> if the UE is in the CELL_FACH state and the C_RNTI variable is empty: 4> perform a cell update using the cause "cell reselect". 1> Periodic cell update: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the CELL_FACH or CELL_PCH state; and 2> if timer T305 expires; and 2> if the criteria for "in service area" as specified in sub-item 8.5.5.2 are met; and 2> if a periodic update has been configured by T305 in IE "UE timers and constants in connected mode" set to any value other than "infinite": 3> for FDD: 4> if variable COMMON_E_DCH TRANSMISSION is set to FALSE: 5> perform a cell update using the cause "Periodic cell update". 4> if not: 5> restart timer T3 05; 5> and end of procedure. 3> for TDD of 1.28 Mcps and 3.84/TDD of 7.68 Mcps: 4> perform a cell update using the cause "Periodic cell update". 1> receiving MBMS: 2> if none of the criteria for performing a cell update with the causes specified above in the current sub-item is met; and 2> if the UE is in the URA_PCH, Cell_PCH or Cell_FACH state; and 2> if the UE has to perform a cell update for MBMS count as specified in sub-item 8.7.4: 3> perform a cell update using the cause "MBMS reception".
A UE in the URA_PCH state must start the URA update procedure in the following cases: 1> URA reselection: 2> if the UE detects that the current URA assigned to the UE, stored in the URA_IDENTITY variable, is not present in the list of identities of URA in the type 2 system information block; or 2> if the list of IVR identities in the type 2 system information block is empty; or 2> if the type 2 system information block cannot be found: 3> perform an IVR update using the "IVR change" cause. 1> IVR periodic update: 2> if the criteria for performing an IVR update with the causes as specified above in the current sub-item are not met: 3> if timer T3 05 expires and if a periodic update has been configured by T305 in IE "UE timers and constants in connected mode" set to any value other than "infinite"; or 3> if the conditions for initiating an IVR update procedure specified in sub-item 8.1.1.6.5 are met: 4> perform an IVR update using the cause "IVR periodic update".
When initiating the URA update procedure or cell update procedure, the UE shall: 1> if the UE has the uplink RLC data PDU or the uplink RLC control PDU in THIRD EDGE or up to transmit; or 1> if the UE received a TYPE 1 RADIO CALL message meeting the conditions for initiating a cell update procedure specified in sub-item 8.1.2.3: 2> set counter V316 to zero. 1> if timer T320 is running: 2> stop timer T320; 2> if the UE has an uplink RLC data PDU or an uplink RLC control PDU in RB1 or up to transmit: 3> perform a cell update using the cause "uplink data transmission ". 2> if not: 3> if cell update procedure is not triggered due to Radio Call Answer or Radio Link Failure; and 3> if the UE is to perform a cell update for an MBMS ptp radio bearer request as specified in subitem 8.6.9.6; 4> perform a cell update using the cause "MBMS ptp RB request". 1> stop timer T319 if it is running; 1> stop timer T305; 1> for FDD and TDD of 1.28 Mcps: 2> if UE is in CELL_FACH state; and 2> if the IE "HS-DSCH common system information" is included in the type 5 system information block or type 5bis System Information Block; and 2> for TDD of 1.28 Mcps, if the IE "Common E-DCH System Information" in the type 5 system information block; and 2> if the UE does not support an HS-DSCH reception in the CELL_FACH state: 3> if the H_RNTI variable is not set or the C_RNT1 variable is not set: 4> clear the H_RNTI variable; 4> clear the C_RNTI variable; 4> clear any IEs stored "HARQ information"; 4> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 4> and begin to receive the physical channels mapped from HS-DSCH transport channels of type HS-SCCH and HS-PDSCH, by using parameters given by the IE(s) "HS-DSCH common system information" according to the procedure in subitem 8.5.37. 3> if not: 4> receive the physical channels mapped from HS-DSCH transport channels of type HS-SCCH and HS-PDSCH, by the use of parameters given by the IE(s) "HS-DSCH common system information " in accordance with the procedure in subitem 8.5.36; 4> determine the value for the variable HSPA_RNTI_STORED_CELL_PCH and take the corresponding measures as described in subitem 8.5.56; 4> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 4> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46; 4> if variable READY_FOR_COMMON_EDCH is set to TRUE: 5> configure Enhanced Uplink in CELL_FACH state and in idle mode as specified in subitem 8.5.45 for FDD and 8.5.45a for TDD of 1.28 Mcps. 1> if the UE is in CELL_DCH state: 2> in the RB_TIMER_INDICATOR variable, set the IE "T314 expired" and the IE "T315 expired" to FALSE; 2> if the stored values of timer T314 and timer T315 are both equal to zero; or 2> if the stored value of timer T314 is equal to zero and there are no radio carriers associated with any radio access carriers for which in the variable ESTABLISHED_RABS the value of the IE "Timer Reset" is set to "useT315" and a signaling connection exists only in the CS domain: 3> release all its radio resources; 3> indicate to release (abort) established signaling connections (as stored in ESTABLISHED_SIGNALLING_CONNECTIONS variable) and established radio access bearers (as stored in ESTABLISHED_RABS variable) to higher layers; 3> clear the ESTABLISHED_SIGNALLING_CONNECTIONS variable; 3> clear the ESTABLISHED_RABS variable; 3> enter idle mode; 3> perform other actions when entering idle mode from connected mode, as specified in sub-item 8.5.2; 3> and the procedure ends. 2> if the stored value of timer T314 is equal to zero: 3> release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to " useT314"; 3> in the variable RB_TIMER_INDICATOR set the IE "T314 expired" to TRUE; 3> if all radio access bearers associated with a CN domain are released: 4> release the signaling connection for that CN domain; 4> remove the signaling connection for that CN domain from the ESTABLISHED_SIGNALLING_CONNECTIONS variable; 4> indicate to release (abort) the signaling connection to higher layers; 2> if the stored value of timer T315 is equal to zero: 3> release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT315 "; 3> in the variable RB_TIMER_INDICATOR set the IE "T315 expired" to TRUE. 3> if all radio access bearers associated with a CN domain are released: 4> release the signaling connection for that CN domain; 4> remove the signaling connection for that CN domain from the ESTABLISHED_SIGNALLING_CONNECTIONS variable; 4> indicate to release (abort) the signaling connection to higher layers; 2> if the stored value of timer T314 is greater than zero: 3> if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT314 ": 4> start timer T314. 3> if there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT314" or "useT315" and the signaling connection exists for the domain of CS: 4> start timer T314. 2> if the stored value of timer T315 is greater than zero: 3> if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE "Reset timer" is set to "useT315 "; or 3> if signaling connection exists for PS domain: 4> start timer T315, 2> for freed radio bearer(s): 3> clear radio bearer information from the variable ESTABLISHED_RABS; 3> when all radio bearers belonging to the same radio access bearer have been released: 4> indicate local end release of the radio access bearer to higher layers using the domain identity of CN together with the identity of RAB stored in the variable ESTABLISHED_RABS; 4> delete all information about the radio access bearer from the variable ESTABLISHED_RABS. 2> if the E_DCH_TRANSMISSION variable is set to TRUE: 3> set the E_DCH_TRANSMISSION variable to FALSE; 3> stop any E-AGCH and E-HICH receiving procedures; 3> for FDD, stop any E-RGCH receiving procedures. 3> for FDD, stop any E-DPCCH and E-DPDCH transmission procedures. 3> for 1.28 Mcps TDD, stop any E-PUCH transmission procedure. 3> clear the E_RNTI variable; 3> act as if the IE "reset MAC-es/e indicator" had been received and was set to TRUE; 3> release all HARQ resources of E-DCH; 3> no longer consider any radio link to be the service E-DCH radio link. 2> move to CELL_FACH state; 2> select a suitable UTRA cell at the current frequency according to [4]; 2> clear the E_RNTI variable and: 3> determine the value for the HSPA_RNTI_STORED_CELL_PCH variable and take the corresponding measures as described in subitem 8.5.56; 25 3> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 3> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46. 2> for TDD of 2.84 Mcps and TDD of 7.68 Mcps; or 2> for FDD and TDD of 1.28 Mcps, if the UE does not support an HS-DSCH reception in the CELL_FACH state; or 2> if the IE "HS-DSCH common system information" is not included in the type 5 system information block or the type 5bis System Information Block; or 2> for TDD of 1.28 Mcps, if IE "Common E-DCH System Information" is not included in Type 5 System Information Block: 3> Select PRACH according to subitem 8.5.17; 3> select Secondary CCPCH according to subitem 8.5.19; 3> use the transport format setting given in the system information as specified in subitem 8.6.5.1; 3> take the measures related to the variable HS_DSCH_RECEPTION_GENERAL as described in subitem 8.5.37a. 2> otherwise.- 3> if the READY_FOR_COMMON_EDCH variable is set to TRUE: 4> configure the Enhanced Uplink in CELL_FACH state and in idle mode as specified in subitem 8.5.45. 3> if not: 4> select PRACH according to subitem 8.5.17 and: 5> use for the PRACH the transport format setting given in the system information as specified in subitem 8.6.5.1. 3> clear the H_RNTI variable; 3> clear any IEs stored "HARQ information"; 3> reset the MAC-ehs entity [15]; 3> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 3> and start receiving the HS-DSCH according to the procedure in subitem 8.5.37. 2> set the ORDERED_RECONFIGURATION variable to FALSE. 1> set the PROTOCOL_ERROR_INDICATOR, FAILURE_INDICATOR, UNSUPPORTED_CONFIGURATION and INVALID_CONFIGURATION variables to FALSE; 1> set the CELL_UPDATE_STARTED variable to TRUE; 1> if any HS-DSCHAre related IEs stored in the UE: 2> clear any stored IE "Downlink HS-PDSCH Information"; 2> clear any stored IE "Downlink Secondary Cell Information FDD"; 2> clear all entries for the TARGET_CELL_PRECONFIGURATION variable; 2> for TDD of 1.28 Mcps, clear IE "Intermediate Block Configuration of HS-PDSCH" and IE "Regular Configuration of HS-SCCH" in IE "Multi-Carrier DL Information"; 2> determine the value for the variable HS DSCH RECEPTION and take the corresponding measures as described in subitem 8.5.25; 2> determine the value for the variable SECONDARY_CELL_HS_DSCH_RECEPTION and take the corresponding measures as described in subitem 8.5.51. 1> if any E-DCH related IEs are stored in the UE: 2> clear any stored IE "E-DCH information" ; 2> determine the value for the variable E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.28. 1> if any of the IEs "DTX-DRX Sync Information" or "DTX-DRX Information" is stored in the UE: 15 2> determine the value for the variable DTX_DRX_STATUS and take the corresponding measures as described in subitem 8.5. 34. 1> if the IE "Information less than HS-SCCH" is stored in the UE: 2> determine the value for the variable HS_SCCH_LESS_STATUS and take the corresponding measures as described in subitem 8.5.35. 1> if any MIMO-related IEs are stored in the UE: 2> determine the value for the variable MIMO_STATUS and take the corresponding measures as described in subitem 8.5.33. 1> for TDD of 1.2 8 Mcps, if the IEs "Control Channel DRX Information" is stored in the UE: 2> determine the value for the variable
CONTROL_CHANNEL_DRX_STATUS and take the corresponding measures as described in subitem 8.5.53. 1> for TDD of 1.28 Mcps, if the IE "SPS information" is stored in the UE: 2> determine the value for the variable E_DCH_SPS_STATUS and take the corresponding measures as described in subitem 8.5.54; 2> determine the value for the variable HS_DSCH_SPS_STATUS and take the corresponding measures as described in subitem 8.5.55. 1> if the UE is not yet in the CELL_FACH state; 2> move to CELL_FACH state; 2> determine the value for the variable HSPA_RNTI_STORED_CELL_PCH and take the corresponding measures as described in subitem 8.5.56; 2> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 2> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46; 2> for TDD of 2.84 Mcps and TDD of 7.68 Mcps; or 2> for FDD and TDD of 1.28 Mcps, if the UE does not support an HS-DSCH reception in the CELL_FACH state; or 2> if the IE "HS-DSCH common system information" is not included in the type 5 system information block or type 5bis System Information Block; or 2> for TDD of 1.28 Mcps, if IE "Common E-DCH System Information" is not included in Type 5 System Information Block: 3> Select PRACH according to subitem 8.5.17; 3> select Secondary CCPCH according to subitem 8.5.19; 3> use the transport format setting given in the system information as specified in subitem 8.6.5.1 ; 3> take the measures related to the variable HS_DSCH_RECEPTION_GENERAL as described in subitem 8.5.37a. 2> if not: 3> if variable READY_FOR_COMMON_EDCH is set to TRUE: 4> configure Enhanced Uplink in CELL_FACH state and in idle mode as specified in subitem 8.5.45. 3> if not: 4> select PRACH according to subitem 8.5.17 and: 5> use for the PRACH the transport format setting given in the system information as specified in subitem 8.6.5.1. 3> if variable H_RNTI is not set or variable CJRNT1 is not set: 4> clear variable C_RNTI; 4> clear the H_RNTI variable; 4> clear any IEs stored "HARQ information"; 4> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 4> and start receiving the HS-DSCH according to the procedure in subitem 8.5.37. 3> if not: 4> receive the HS-DSCH according to the procedure in subitem 8.5.36. 1> if the UE performs a cell reselection: 2> clear the C_RNTI variable; and 2> stop using that C_RNTI just cleared from the C_RNTI variable in MAC; 2> for FDD and TDD of 1.28 Mcps, if variable H_RNTI is set: 3> clear variable H_RNTI; and 3> stop using that newly cleared H_RNTI from the H_RNTI variable in MAC; 3> clear any IEs stored "HARQ information"; 2> for FDD and TDD of 1.28 Mcps, if variable E_RNTI is set: 3> clear variable E_RNTI. 2> determine the value for the variable HSPA_RNTI_STORED_CELL_PCH and take the corresponding measures as described in subitem 8.5.56; 2> determine the value for the variable READY_FOR_COMMON_EDCH and take the corresponding measures as described in subitem 8.5.47; 2> determine the value for the variable COMMON_E_DCH_TRANSMISSION and take the corresponding measures as described in subitem 8.5.46; 2> for 1.28 Mcps FDD and TDD, if the UE does not support an HS-DSCH reception in the CELL_FACH state and the IE "HS-DSCH common system information" is included in the type 5 system information block or System Information Block of type 5bis: 3> reset the MAC-ehs entity [15]. 3> set the HS_DSCH_RECEPTION_OF_CCCH_ENABLED variable to TRUE; 3> and start receiving the HS-DSCH according to the procedure in subitem 8.5.37. 2> else; 3> take the measures related to the variable HS_DSCH_RECEPTION_GENERAL as described in subitem 8.5.37a. 1> regulate CFN in relation to current cell SFN according to subitem 8.5.15; 1> in case of a cell update procedure: 2> regulate the content of the CELL UPDATE message according to sub-item 8.3.1.3; 2> submit the CELL UPDATE message for transmission on the uplink CCCH. 1> in the case of an IVR Update Procedure: 2> regulate the content of the IVR UPDATE message according to sub-item 8.3.1.3; 2> submit the URA UPDATE message for transmission on the uplink CCCH. 1> set counter V302 to 1; 1> Start timer T302 when MAC layer indicates message transmission success or failure. 10.3.3.43 UE and Constant Timers in Connected Mode
This information element specifies timer values and constants used by the UE in connected mode.





13.4.27x TRIGGERED_SCRI_IN_PCH_STATE
This variable contains information as to whether a SIGNALING CONNECTION RELEASE INDICATION message was triggered in CELL_PCH or URA_PCH states. There is a 5 variable like this in the UE.



Appendix D
As of 25,331 section 8.2.2, Figure 8.2.2-3: describes a radio bearer reconfiguration, normal flow. The message is described here, with the proposed addition in bold italics: 10.2.27 RADIO CARRIER RESET
This message is sent from the UTRAN for the reconfiguration of parameters related to a 10 QoS change or a connection and an establishment of a radio bearer used for ptp transmission of broadcast type MBMS services. This procedure can also change MAC multiplexing, reconfigure transport channels and physical channels. This message is also used for performing an Iu mode point-to-point transfer from GERAN to UTRAN. RLC-SAP: AM or UM or sent via GERAN lu mode Logical channel: DCCH or sent via GERAN lu mode Direction: UTRAN -» UE

权利要求:
Claims (30)
[0001]
1. Method performed by a user equipment (UE), the method characterized in that it comprises: in the UE, maintaining a count of signaling connection release indication (SCRI) messages sent by the UE (700) to the network while the UE (700) is held in a radio resource control (RRC) state; transmitting a signaling by the UE (700) on a radio carrier 3 (RB3) or above; resetting the count by the UE (700) in response to transmitting the signaling, wherein the UE (700) is configured to be inhibited from sending SCRI messages in the event that the count is equal to or greater than a predetermined value.
[0002]
2. Method according to claim 1, characterized in that the signaling comprises an uplink radio link control (RLC) protocol data unit (PDU).
[0003]
3. Method according to claim 1 or 2, characterized in that the signaling connection release indication messages (SCRI) sent by the UE (700) each have a regulated cause.
[0004]
4. Method according to claim 3, characterized by the fact that the cause is set to "UE Requested PS data session end".
[0005]
5. Method according to any one of claims 1, 2, 3 or 4, characterized in that the RRC state comprises a CELL_PCH state or a URA_PCH state.
[0006]
6. Method according to any one of claims 1, 2, 3, 4 or 5, characterized in that the maintenance of a count comprises the use of a counter.
[0007]
7. Method according to any one of claims 1, 2, 3, 4, 5, or 6, characterized in that said maintenance includes incrementing the count.
[0008]
8. Method according to any one of claims 1, 2, 3, 4, 5, 6 or 7, characterized in that maintenance includes incrementing, while in a radio call channel (PCH) state, the count to reflect the UE (700) causing a SCRI message to be sent, each SCRI message counted having a cause set to "UE requested end of PS data session", the method further comprising: determining whether a current value of the count is equal to or greater than a predetermined value; and responsive to the determination, stop sending other SCRI messages with a cause set to “UE requested PS data logout”.
[0009]
9. Method according to any one of claims 1, 2, 3, 4, 5, 6, 7 or 8, characterized in that it further comprises determining whether a current count value is less than the predetermined value.
[0010]
10. Method according to any one of claims 1, 2, 3, 4, 5, 6, 7, 8 or 9 characterized in that the predetermined value is 1.
[0011]
11. User equipment (UE) (700), comprising a processor, characterized in that it is configured to: maintain a count of signaling connection release indication (SCRI) messages sent by the UE (700) to a network, while the UE (700) is kept in a current radio resource control (RRC) state; transmitting a signaling by the UE (700) on a radio carrier 3 (RB3) or above; resetting the count by the UE (700) in response to transmitting the signaling, wherein the UE (700) is configured to be inhibited from sending SCRI messages in the event that the count is equal to or greater than a predetermined value.
[0012]
12. User equipment (700) according to claim 11, characterized in that the signaling comprises an uplink radio link control (RLC) protocol data unit (PDU).
[0013]
13. User equipment (700) according to claim 11 or 12, characterized in that signaling connection release indication messages (SCRI) sent by the UE (700) each have a regulated cause.
[0014]
14. User Equipment (UE) (700), according to claim 13, characterized in that the cause is set to "UE Requested PS data session end".
[0015]
15. User equipment (UE) (700) according to any one of claims 11, 12, 13 or 14, characterized in that the RRC state comprises a CELL_PCH state or an URA_PCH state.
[0016]
16. User equipment (700) according to any one of claims 11, 12, 13, 14 or 15, characterized in that the maintenance of a count further comprises the use of a counter.
[0017]
17. User equipment (700) according to any one of claims 11, 12, 13, 14, 15, 16 or 17, characterized in that said maintenance includes incrementing the count.
[0018]
18. User equipment (700) according to any one of claims 11, 12, 13, 14, 15 or 16, characterized in that maintenance includes incrementing while in a radio call channel (PCH) state ), the count to reflect the UE (700) causing a SCRI message to be sent, each SCRI message counted having a regulated cause for "UE requested end of PS data session", the UE (700) comprises a still a processor configured to: determine whether a current count value is equal to or greater than a predetermined value; and responsive to the determination, stop sending other SCRI messages with a cause set to “UE requested PS data logout”.
[0019]
19. Method performed by a user equipment (UE), the method characterized in that it comprises: in the UE, maintaining a count of signaling connection release indication (SCRI) messages sent by the UE (700) to a network while in at least one radio resource control (RRC) state; entering connected mode of RRC; and resetting the count in response to entering the RRC connected mode, wherein the UE (700) is configured to be inhibited from sending SCRI messages in the event that the count is equal to or greater than a predetermined value.
[0020]
20. Method according to claim 19, characterized in that signaling connection release indication messages (SCRI) sent by the UE (700), each has a regulated cause.
[0021]
21. Method according to claim 20, characterized by the fact that the cause is regulated to "UE Requested PS data session end".
[0022]
22. Method according to any one of claims 19, 20, or 21, characterized in that at least one state of RRC comprises a state CELL_PCH or a state URA_PCH.
[0023]
23. Method according to any one of claims 19, 20, 21, or 22, characterized in that the maintenance of a count comprises the use of a counter.
[0024]
24. Method according to any one of claims 19, 20, 21, 22 or 23, characterized in that said maintenance includes incrementing the count.
[0025]
25. User equipment (UE) (700), comprising a processor, characterized in that it is configured to: maintain a count of signaling connection release indication (SCRI) messages sent by the UE (700) to a network while in at least one radio resource control (RRC) state; entering connected mode of RRC; and resetting the count in response to entering the RRC connected mode, wherein the UE (700) is configured to be inhibited from sending SCRI messages in the event that the count is equal to or greater than a predetermined value.
[0026]
26. User equipment according to claim 25, characterized in that the signaling connection release indication (SCRI) messages sent by the UE (700) each have a regulated cause.
[0027]
27. User equipment according to claim 26, characterized by the fact that the cause is regulated to "UE Requested PS data session end".
[0028]
28. User equipment according to claim 25, characterized in that at least one state of 10 RRC comprises a CELL_PCH state or an URA_PCH state.
[0029]
29. Method according to any one of claims 26 to 28, characterized in that the maintenance of a count comprises the use of a counter.
[0030]
30. User equipment (700) according to any one of claims 26 to 29, characterized in that said maintenance includes counting increments.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012012362B1|2021-05-18|method and apparatus for state/mode transition

---

BR112012012356B1|2021-05-04|methods and user equipment for processing indication messages

---

CN107018579B|2021-02-19|State or mode transition triggering based on SRI message transmission

---

JP5551275B2|2014-07-16|Method and apparatus for status / mode transmission

---

JP5583225B2|2014-09-03|Method and apparatus for state / mode transition

---

AU2014203095A1|2014-09-04|State or mode transition triggering based on SRI message transmission

同族专利:

---

公开号 | 公开日

---

US20110182193A1|2011-07-28|

---

KR101468855B1|2014-12-03|

---

JP5525620B2|2014-06-18|

---

US8310970B2|2012-11-13|

---

CA3038940A1|2011-05-26|

---

AU2010321204A1|2012-06-28|

---

EP2592895B1|2014-07-23|

---

US9467976B2|2016-10-11|

---

KR20120099083A|2012-09-06|

---

EP2505033A1|2012-10-03|

---

US9226271B2|2015-12-29|

---

KR20140099936A|2014-08-13|

---

CA2781630A1|2011-05-26|

---

US20130188543A1|2013-07-25|

---

AU2010321204B2|2014-11-20|

---

US8305924B2|2012-11-06|

---

US9521657B2|2016-12-13|

---

EP2592895A1|2013-05-15|

---

EP2592894B1|2016-04-27|

---

JP2013511872A|2013-04-04|

---

EP2592894A1|2013-05-15|

---

ES2494193T3|2014-09-15|

---

EP3691347B1|2022-02-16|

---

CN102754517B|2015-12-16|

---

US20120033626A1|2012-02-09|

---

CA2781630C|2019-05-21|

---

EP3691347A1|2020-08-05|

---

JP5976031B2|2016-08-23|

---

WO2011060997A1|2011-05-26|

---

CN102754517A|2012-10-24|

---

US20120051289A1|2012-03-01|

---

MX2012005873A|2012-11-30|

---

US20130316720A1|2013-11-28|

---

CA3038940C|2021-04-27|

---

JP2014161077A|2014-09-04|

---

BR112012012362A2|2020-11-03|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

SE469736B|1992-02-05|1993-08-30|Ericsson Telefon Ab L M|ERROR MANAGEMENT IN RADIOL COUPLES|

---

JP3161910B2|1994-07-26|2001-04-25|シャープ株式会社|Communication device|

---

DE69509804T2|1995-06-14|1999-12-09|Ibm|DATA PACKAGE TRANSFER IN CODEMULTIPLEX MULTIPLE ACCESS SYSTEMS|

---

JPH0955764A|1995-08-14|1997-02-25|Nippon Telegr & Teleph Corp <Ntt>|Radio packet communication method|

---

FI103454B1|1996-04-01|1999-06-30|Nokia Telecommunications Oy|Control of the operation of a mobile station in a packet radio system|

---

US5812636A|1996-09-06|1998-09-22|Northern Telecom Limited|System and method for faulty mobile unit isolation|

---

KR100232881B1|1997-10-08|1999-12-01|윤종용|Method of controlling power for receiver and pager therefor|

---

WO1999034534A1|1997-12-30|1999-07-08|Ericsson, Inc.|A unified antenna diversity switching system for tdma-based telephones|

---

JPH11313370A|1998-04-28|1999-11-09|Toshiba Corp|Mobile packet communication system, its data communication device, base station device and mobile terminal|

---

JPH11331947A|1998-05-18|1999-11-30|Nippon Telegr & Teleph Corp <Ntt>|Radio station, radio data communication method and program storage medium|

---

US6064340A|1998-07-02|2000-05-16|Intersil Corporation|Electrostatic discharge locating apparatus and method|

---

KR20000014143A|1998-08-14|2000-03-06|서평원|Improved method of transmitting pilot strength measurement message in communication system|

---

FI108203B|1998-11-27|2001-11-30|Nokia Mobile Phones Ltd|Method and apparatus for transmitting information in a packet radio service|

---

US6223044B1|1998-12-18|2001-04-24|Telefonaktiebolaget Lm Ericsson|Adaptive location level|

---

EP1142420B1|1999-01-04|2006-07-19|Telefonaktiebolaget LM Ericsson |Bearer service negotiation|

---

US6275712B1|1999-02-26|2001-08-14|Nokia Mobile Phones Ltd|Mobile station control states based on available power|

---

EP1033846A1|1999-03-01|2000-09-06|Alcatel|Process for controlling uplink packet transmission in a wireless communication network|

---

US6377790B1|1999-03-08|2002-04-23|Sharp Laboratories Of America, Inc.|Mobile-initiated, packet switched communications method|

---

US6965778B1|1999-04-08|2005-11-15|Ipr Licensing, Inc.|Maintenance of channel usage in a wireless communication system|

---

IL139792A|1999-04-12|2005-07-25|Samsung Electronics Co Ltd|Method for controlling gated transmission of dedicated channel in w-cdma communication system|

---

SE522068C2|1999-07-15|2004-01-13|Ericsson Telefon Ab L M|Method and apparatus for providing radio access carrier services|

---

FI107674B|1999-08-30|2001-09-14|Nokia Mobile Phones Ltd|Procedure for optimizing data transmission in a packet switched wireless communication system|

---

JP4277378B2|1999-09-02|2009-06-10|株式会社島津製作所|Cooling system|

---

US6657984B1|1999-10-29|2003-12-02|Samsung Electronics, Co., Ltd.|System and method providing backward compatibility of radio link protocols in a wireless network|

---

US6654360B1|2000-01-10|2003-11-25|Qualcomm Incorporated|Method and system for providing dormant mode wireless packet data services|

---

US6593850B1|2000-01-27|2003-07-15|Pittway Corp.|Wireless intrusion detector with test mode|

---

FI110651B|2000-02-22|2003-02-28|Nokia Corp|A method for checking the amount of data transferred|

---

FI110352B|2000-02-24|2002-12-31|Nokia Corp|Method and arrangement to optimize the re-establishment of connections in a cellular radio system that supports real-time and non-real-time communications|

---

CN1150698C|2000-06-22|2004-05-19|三星电子株式会社|Appts. for gated transmission of dedicated physical control channel and method thereof in mobile communication system|

---

US6748246B1|2000-07-05|2004-06-08|Telefonaktiebolaget Lm Ericsson |Method and apparatus for selecting an access technology in a multi-mode terminal|

---

US7230932B2|2000-08-18|2007-06-12|Nokia Mobile Phones Ltd.|Method and apparatus for discontinuous reception scheme and power saving mode for user equipment in packet access mode|

---

FI109628B|2000-08-21|2002-09-13|Nokia Corp|Method for Reducing the Power Consumption of a Wireless Terminal, a Communication System, and a Wireless Terminal|

---

JP3405331B2|2000-08-22|2003-05-12|ニチハ株式会社|Fastening bracket and outer wall construction structure|

---

US6690655B1|2000-10-19|2004-02-10|Motorola, Inc.|Low-powered communication system and method of operation|

---

US6845236B2|2000-11-01|2005-01-18|Lg Electronics Inc.|Method for concurrent multiple services in a mobile communication system|

---

US6970438B2|2001-02-16|2005-11-29|Nokia Mobile Phones Ltd.|Method and device for downlink packet switching|

---

US7046992B2|2001-05-11|2006-05-16|Telefonaktiebolaget Lm Ericsson |Authentication of termination messages in telecommunications system|

---

JP4015428B2|2001-05-16|2007-11-28|株式会社日立コミュニケーションテクノロジー|RADIO BASE STATION / WIRELESS BASE STATION CONTROL DEVICE, RADIO TERMINAL, AND STATE CONTROL METHOD HAVING IN-ACTIVITY TIMER|

---

US7337019B2|2001-07-16|2008-02-26|Applied Materials, Inc.|Integration of fault detection with run-to-run control|

---

US7221670B2|2001-08-13|2007-05-22|Motorola, Inc.|Apparatus and method for supplying information concerning packet data to a base station|

---

JP4039851B2|2001-12-07|2008-01-30|株式会社エヌ・ティ・ティ・ドコモ|Mobile communication terminal, application program execution state control method, application program, and record recording application program|

---

US7609673B2|2002-02-08|2009-10-27|Telefonaktiebolaget Lm Ericsson |Packet-based conversational service for a multimedia session in a mobile communications system|

---

KR100765123B1|2002-02-16|2007-10-11|엘지전자 주식회사|Method for relocating SRNS|

---

DE60314331T2|2002-05-03|2008-02-14|Innovative Sonic Ltd., Road Town|Method of cell updating via idle for the purpose of saving power in a UMTS mobile after a failed radio connection.|

---

US6981570B2|2002-05-09|2006-01-03|Dalbec Richard H|Loudspeaker system with common low and high frequency horn mounting|

---

US7054630B2|2002-05-13|2006-05-30|Qualcomm Incorporated|Selective processing of the common control channel|

---

JPWO2003105519A1|2002-06-05|2005-10-13|株式会社エヌ・ティ・ティ・ドコモ|Server, mobile communication system, location information management method, radio base station, mobile station, calling method and mobile communication method in mobile communication system|

---

US7068636B2|2002-06-21|2006-06-27|Asustek Computer Inc.|Method for determining RLC entity re-establishment during SRNS relocation|

---

JP4197408B2|2002-06-26|2008-12-17|パナソニック株式会社|COMMUNICATION SYSTEM, TERMINAL DEVICE, AND RELAY STATION SELECTION METHOD FOR COMMUNICATION SYSTEM|

---

US20040192312A1|2002-07-16|2004-09-30|Jia-Ru Li|Communication system for voice and data with wireless TCP server|

---

US6961570B2|2002-07-17|2005-11-01|Asustek Computer Inc.|Handling of a wireless device re-entering a service area|

---

US7152111B2|2002-08-15|2006-12-19|Digi International Inc.|Method and apparatus for a client connection manager|

---

KR100510651B1|2002-09-12|2005-08-31|엘지전자 주식회사|Method for Managing Resource of Mobile Communication System|

---

US7277392B2|2002-10-01|2007-10-02|Motorola, Inc.|Method and apparatus for managing the usage of data link resources|

---

EP2334129A3|2002-10-18|2012-07-11|Kineto Wireless, Inc.|Method and apparatuses for paging a telecommunication device|

---

EP1554906B1|2002-10-23|2009-11-25|Nokia Corporation|Radio resource control method in mobile communication system, and mobile communication system|

---

AT385637T|2002-12-12|2008-02-15|Huawei Tech Co Ltd|METHOD FOR CONSTRUCTION AND REMOVAL OF A SERVICE CONNECTION BETWEEN A WIRELESS LOCAL NETWORK AND A USER DEVICE|

---

US7437172B2|2002-12-10|2008-10-14|Qualcomm Incorporated|Discontinuous transmission detection in wireless communication systems|

---

AT408318T|2002-12-16|2008-09-15|Research In Motion Ltd|METHOD AND DEVICE FOR REDUCING ENERGY CONSUMPTION IN A CDMA COMMUNICATION DEVICE|

---

SE0300047D0|2003-01-08|2003-01-08|Ericsson Telefon Ab L M|MBMS in UTRAN|

---

US7423993B2|2003-02-10|2008-09-09|Nokia Corporation|Connection release in communication network|

---

US6822973B2|2003-02-18|2004-11-23|Motorola, Inc.|Apparatus and method for implementing a reduced slotted mode in a communication system|

---

US7720960B2|2003-03-04|2010-05-18|Cisco Technology, Inc.|Method and apparatus providing prepaid billing for network services using explicit service authorization in an access server|

---

US7787413B2|2003-03-14|2010-08-31|Nortel Networks Limited|Method for mobile station request release of multiple packet data service sessions simultaneously using resource release request messages|

---

JP4350565B2|2003-03-27|2009-10-21|キヤノン株式会社|Information processing apparatus and method|

---

FR2854756B1|2003-05-07|2005-08-12|Evolium Sas|METHOD FOR ESTABLISHING CONNECTION IN A MOBILE RADIOCOMMUNICATION SYSTEM|

---

US20040224669A1|2003-05-08|2004-11-11|Pedlar David W.|Apparatus and method of handling universal terrestrial radio access network radio resource control connecting messages in universal mobile telecommunications system user equipment|

---

JPWO2004114552A1|2003-06-20|2006-07-27|富士通株式会社|WCDMA mobile communication system|

---

US7406314B2|2003-07-11|2008-07-29|Interdigital Technology Corporation|Wireless transmit receive unit having a transition state for transitioning from monitoring to duplex connected states and method|

---

CN100482483C|2003-07-28|2009-04-29|麦格纳国际公司|Frame integrated rear suspension system|

---

KR20050014984A|2003-08-01|2005-02-21|삼성전자주식회사|Methoed for retransmitting rrc connection request in a mobile communication system which support mbms|

---

US20050032555A1|2003-08-07|2005-02-10|Iqbal Jami|Method of intermittent activation of receiving circuitry of a mobile user terminal|

---

KR100548393B1|2003-08-20|2006-02-02|엘지전자 주식회사|Packet service enhancement method for mobile communication terminal|

---

TWI245513B|2003-08-26|2005-12-11|Ind Tech Res Inst|Method and apparatus for controlling multi-radio access|

---

US7130668B2|2003-09-01|2006-10-31|Samsung Electronics Co., Ltd.|Method and system for controlling sleep mode in broadband wireless access communication system|

---

US7634554B2|2003-09-18|2009-12-15|Cisco Technology, Inc.|TTL exploration technique for determining capabilities and configuration of a peer router|

---

GB0322741D0|2003-09-29|2003-10-29|Nortel Networks Ltd|Structured probable causes for management systems and network devices and their exploitation|

---

GB0323246D0|2003-10-03|2003-11-05|Fujitsu Ltd|Virtually centralized uplink scheduling|

---

CN1860737A|2003-10-16|2006-11-08|艾利森电话股份有限公司|Access to CDMA/UMTS service over a WLAN access point, using a gateway node between WLAN access point and service providing network|

---

US7623530B2|2003-11-20|2009-11-24|Nokia Corporation|Indication of service flow termination by network control to policy decision function|

---

JP2005175831A|2003-12-10|2005-06-30|Ntt Docomo Inc|Communication terminal and program|

---

FI20031911A0|2003-12-29|2003-12-29|Nokia Corp|A method and system for controlling an access network service in a real-time data service|

---

FI20031912A0|2003-12-29|2003-12-29|Nokia Corp|Procedure and system for controlling a real-time communication service|

---

US20050143056A1|2003-12-31|2005-06-30|Iyer Prakash R.|Method and apparatus for providing push-to-talk services in a cellular communication system|

---

US20050149940A1|2003-12-31|2005-07-07|Sychron Inc.|System Providing Methodology for Policy-Based Resource Allocation|

---

ES2287647T3|2004-01-09|2007-12-16|M-Stack Limited|APPARATUS AND METHOD FOR PRACTICE THE DETECTION OF SYSTEM INFORMATION CHANGES IN UNIVERSAL MOBILE TELECOMMUNICATION SYSTEMS .|

---

KR100664278B1|2004-01-09|2007-01-04|엘지전자 주식회사|Radio communication system providing mbms|

---

US7440459B2|2004-02-02|2008-10-21|Lucent Technologies Inc.|Methods of detecting protocol support in wireless communication systems|

---

US7480267B2|2004-02-06|2009-01-20|M-Stack Limited|Apparatus and method for operating a communications device in a mobile communications network|

---

US7519035B2|2004-02-23|2009-04-14|Sharp Laboratories Of America, Inc.|Method to negotiate consumed power versus medium occupancy time in MIMO based WLAN systems using admission control|

---

GB0406664D0|2004-03-24|2004-04-28|Samsung Electronics Co Ltd|Mobile communications|

---

US7636331B2|2004-04-19|2009-12-22|Lg Electronic Inc.|Transmission of control information in wireless communication system|

---

KR100703487B1|2004-04-21|2007-04-03|삼성전자주식회사|The Method For Efficient Packet Data Service in UMTS system|

---

US20050245267A1|2004-04-30|2005-11-03|Guethaus Roland J|Methods of allocating a channel to baseband processing units in a communication system|

---

EP1596616A1|2004-05-14|2005-11-16|Research In Motion Limited|Method and apparatus for expeditiously releasing network resources for a mobile station based on low battery and lost signal conditions|

---

US20050265350A1|2004-05-28|2005-12-01|Murali Narasimha|Concurrent packet data session set-up for push-to-talk over cellular|

---

US7580388B2|2004-06-01|2009-08-25|Lg Electronics Inc.|Method and apparatus for providing enhanced messages on common control channel in wireless communication system|

---

US7181215B2|2004-06-02|2007-02-20|Sony Ericsson Mobile Communications Ab|Automatic GPRS/EDGE re-attach|

---

US8855572B2|2004-06-16|2014-10-07|Qualcomm Incorporated|Method and apparatus for link control in wireless communications|

---

KR100605625B1|2004-06-17|2006-07-31|엘지전자 주식회사|method for deleting a session of the UMTS|

---

US7089012B2|2004-07-29|2006-08-08|Motorola, Inc.|Method and system for use in reducing cost associated with lost connections in wireless communication|

---

CN1998258A|2004-08-05|2007-07-11|三菱电机株式会社|Base station, mobile communication terminal device, and primary cell selecting method|

---

US7529354B2|2004-08-10|2009-05-05|Nokia Corporation|Method of managing a connection release, corresponding system and device|

---

US8254921B2|2004-08-12|2012-08-28|Qualcomm Incorporated|Default configurations with differential encoding in a wireless communication system|

---

AU2005272283B2|2004-08-13|2008-02-21|Lg Electronics Inc.|Establishment of radio resource control connection in wireless communication system|

---

KR101000682B1|2004-08-13|2010-12-10|엘지전자 주식회사|Rrc connection configuration method in mobile communication system|

---

CN101036099A|2004-09-03|2007-09-12|田纳西太平洋集团有限公司|Centralized management of digital rights licensing|

---

US7904094B2|2004-10-27|2011-03-08|Motorola Mobility, Inc.|Method for reducing wireless communication procedure failure|

---

US20060094478A1|2004-11-04|2006-05-04|Lg Electronics Inc.|Mobile power handling method and apparatus|

---

CN1297109C|2004-11-11|2007-01-24|华为技术有限公司|Method for reading multimedia broadcasting/group broadcasting service switch-in information|

---

US8379553B2|2004-11-22|2013-02-19|Qualcomm Incorporated|Method and apparatus for mitigating the impact of receiving unsolicited IP packets at a wireless device|

---

US20060176167A1|2005-01-25|2006-08-10|Laser Shield Systems, Inc.|Apparatus, system, and method for alarm systems|

---

US8620314B2|2005-03-10|2013-12-31|Qualcomm Incorporated|Apparatus and methods for determining connection quality of a wireless device on a wireless communications network|

---

US7925290B2|2005-03-31|2011-04-12|Qualcomm Incorporated|System and method for efficiently providing high-performance dispatch services in a wireless system|

---

JP4577505B2|2005-03-31|2010-11-10|日本電気株式会社|Method for contention relief between downlink RRC message and inter-cell movement of mobile station in mobile communication system|

---

US7283819B2|2005-04-25|2007-10-16|Research In Motion Limited|Method and apparatus for CDMA timer-based registration on a mobile device|

---

EP1891825B1|2005-06-15|2013-05-15|Intellectual Ventures I LLC|Rrc signalling for fast hs-dsch serving cell change|

---

US20060293067A1|2005-06-27|2006-12-28|Leung Kin K|Method and apparatus for controlling sleep intervals of a mobile unit|

---

DE202005021930U1|2005-08-01|2011-08-08|Corning Cable Systems Llc|Fiber optic decoupling cables and pre-connected assemblies with toning parts|

---

JP4767626B2|2005-08-24|2011-09-07|ドコモ・テクノロジ株式会社|Mobile station, radio access network apparatus, mobile switching center, and communication service access method|

---

EP1938644B1|2005-08-24|2013-04-17|Nokia Corporation|Apparatus, method and computer program to configure a radio link protocol for internet protocol flow|

---

US8094595B2|2005-08-26|2012-01-10|Qualcomm Incorporated|Method and apparatus for packet communications in wireless systems|

---

US7643838B2|2005-09-29|2010-01-05|Motorola, Inc.|Integrity protection count synchronization method|

---

US7761097B2|2005-10-31|2010-07-20|Research In Motion Limited|Apparatus, and associated method, for permitting communication system transition based upon signal threshold determination|

---

US7720482B2|2005-10-31|2010-05-18|Research In Motion Limited|Method and apparatus for transitioning between EVDO and CDMA 1X systems using redundant data call blockings|

---

US7894375B2|2005-10-31|2011-02-22|Research In Motion Limited|Method, and associated apparatus, for transitioning communications of hybrid access terminal between communication systems|

---

US7768962B2|2005-11-01|2010-08-03|Nokia Corporation|HSUPA HARQ process flushing|

---

GB2445336B|2005-11-04|2010-12-08|Nec Corp|Wireless communication system and method of controlling a transmission power|

---

EP2247146B1|2005-12-14|2011-11-16|Research In Motion Limited|Method and apparatus for user equipment directed radio resource control in a UMTS network|

---

CN101341673A|2005-12-19|2009-01-07|Lg电子株式会社|Method for reading dynamic system information blocks|

---

EP2205027B1|2005-12-22|2011-11-09|Electronics and Telecommunications Research Institute|Methodfor discontinuous transmission/reception operation for reducing power consumption in cellular system|

---

US7353120B2|2006-01-24|2008-04-01|Research In Motion Limited|Electrostatic discharge monitoring and manufacturing process control system|

---

WO2007097670A1|2006-02-27|2007-08-30|Telefonaktiebolaget L M Ericsson |Method and apparatus for communication|

---

EP2019512B1|2006-05-18|2010-09-15|Huawei Technologies Co., Ltd.|A method and system for a ue in spare mode logging out a network|

---

CN101411095B|2006-03-28|2013-06-19|三星电子株式会社|Method and apparatus for discontinuous reception of connected terminal in a mobile communication system|

---

CN101427489B|2006-04-25|2012-11-28|三星电子株式会社|Method and apparatus for radio connection setup in a mobile communication system|

---

CN101449525B|2006-04-29|2016-08-10|皇家飞利浦电子股份有限公司|Control the method and device of energy consumption of sensor network nodes|

---

ES2353609T3|2006-05-17|2011-03-03|Research In Motion Limited|METHOD AND SYSTEM FOR INDICATION OF SIGNALING CONNECTION RELEASE IN A UMTS NETWORK.|

---

US8265034B2|2006-05-17|2012-09-11|Research In Motion Limited|Method and system for a signaling connection release indication|

---

AU2007202206C1|2006-05-17|2011-02-10|Blackberry Limited|Method and system for signaling release cause indication in a UMTS network|

---

CN100499869C|2006-05-24|2009-06-10|华为技术有限公司|Terminal equipment accessing method and system|

---

US7852817B2|2006-07-14|2010-12-14|Kineto Wireless, Inc.|Generic access to the Iu interface|

---

CN101114988B|2006-07-24|2010-12-29|中兴通讯股份有限公司|Flow control algorithm for non-continuous emission based forecasting self-adaption multi-velocity service|

---

EP1892895A1|2006-08-25|2008-02-27|Research In Motion Limited|Apparatus, and associated method, for releasing a data service radio resource allocated to a data service capable mobile node|

---

US20080049662A1|2006-08-25|2008-02-28|Research In Motion Limited|Apparatus, and associated method, for releasing a data-service radio resource allocated to a data-service-capable mobile node|

---

US8630604B2|2006-11-17|2014-01-14|Industrial Technology Research Institute|Communication methods and devices for dual-mode communication systems|

---

US8311046B2|2006-11-28|2012-11-13|Core Wireless Licensing S.A.R.L.|Method for the delivery of messages in a communication system|

---

JP2008141252A|2006-11-29|2008-06-19|Sharp Corp|Communications device, communications method, communications circuit, communications system, program, and computer-readable storage medium containing the program|

---

US8515478B2|2006-12-18|2013-08-20|Qualcomm Incorporated|Fast state transition for a UE with reconfiguration over paging|

---

CN101675693B|2007-03-06|2013-07-10|株式会社Ntt都科摩|Mobile station, base station device, wireless communication system and communication control method|

---

KR101381475B1|2007-04-13|2014-04-04|삼성전자주식회사|Method of transiting RRC state into IDLE state of user equipment and system therefor and the user equipment|

---

US20080304510A1|2007-06-08|2008-12-11|Hai Qu|Method and apparatus for controlling radio connection based on inputs from applications|

---

US9887813B2|2007-06-13|2018-02-06|Qualcomm Incorporated|Protocol data unit recovery|

---

US7925233B2|2007-07-20|2011-04-12|Htc Corporation|Methods for handling measurement reports in a wireless communication system|

---

US20090028084A1|2007-07-25|2009-01-29|High Tech Computer, Corp.|Method for reducing user equipment power consumption under a communication network|

---

US8160012B2|2007-08-10|2012-04-17|Lg Electronics Inc.|Methods of setting up channel in wireless communication system|

---

EP2271168A1|2007-08-20|2011-01-05|Research In Motion Limited|Method and system for a signaling connection release indication|

---

KR100937432B1|2007-09-13|2010-01-18|엘지전자 주식회사|Method of allocating radio resources in a wireless communication system|

---

KR101370909B1|2007-10-01|2014-03-19|엘지전자 주식회사|Method of Fast Uplink Data Transmission for handover|

---

KR101487557B1|2007-10-23|2015-01-29|엘지전자 주식회사|Method for transmitting data of common control channel|

---

EP2387283B1|2007-11-13|2018-11-28|BlackBerry Limited|Method and apparatus for state/mode transitioning|

---

CN101453742B|2007-12-04|2010-09-08|大唐移动通信设备有限公司|Cell updating method, equipment and system|

---

TW200931918A|2007-12-07|2009-07-16|Interdigital Patent Holdings|Method and apparatus for supporting configuration and control of the RLC and PDCP sub-layers|

---

TW201511499A|2007-12-10|2015-03-16|Interdigital Patent Holdings|Method and apparatus for triggering radio link control packet discard and radio link control re-establishment|

---

ES2392813T3|2007-12-20|2012-12-14|Telefonaktiebolaget L M Ericsson |Release of enhanced dedicated channel radio resources, E-DCH, common|

---

WO2009104086A1|2008-02-22|2009-08-27|Nokia Corporation|Mobile equipment autonomous quick release detection|

---

US20090221277A1|2008-02-29|2009-09-03|Palm, Inc.|Disconnection techniques in wireless communications networks|

---

US8357752B2|2008-04-23|2013-01-22|Armstrong World Industries, Inc.|Tinted spray buff and tiecoat|

---

GB2461159B|2008-06-18|2012-01-04|Lg Electronics Inc|Method for transmitting Mac PDUs|

---

US8824305B2|2008-07-09|2014-09-02|Qualcomm Incorporated|Paging schemes for local network access|

---

US8737294B2|2008-08-11|2014-05-27|Via Telecom Co., Ltd.|Apparatus and method for handling RLC retransmission failure according to activation status of security mode|

---

JP5233504B2|2008-08-25|2013-07-10|富士通株式会社|Route control apparatus and packet discarding method|

---

US9094910B2|2008-09-09|2015-07-28|Htc Corporation|Methods utilized in mobile device for handling situations when time alignment timer expires, and mobile device thereof|

---

US8391239B2|2008-09-22|2013-03-05|Qualcomm Incorporated|Bearer count alignment during inter-rat handover|

---

EP2356878B1|2008-11-10|2015-07-29|BlackBerry Limited|Method and apparatus of transition to a battery efficient state or configuration by indicating end of data transmission in long term evolution|

---

KR101186619B1|2009-03-29|2012-09-27|엘지전자 주식회사|Method for trasmitting control information in wireless communication system and apparatus therefor|

---

US8902827B2|2009-04-21|2014-12-02|Htc Corporation|Relay for handling data forwarding in a wireless communication system and related method for controlling the same|

---

US8638711B2|2009-08-11|2014-01-28|Qualcomm Incorporated|Systems and methods of maintaining core network status during serving radio network subsystem relocation|

---

ES2805149T3|2009-11-23|2021-02-10|Blackberry Ltd|State or mode transition trigger based on the transmission of a connection release signaling indication message|

---

AU2010320843B2|2009-11-23|2014-07-10|Blackberry Limited|Method and apparatus for state/mode transitioning|

---

AU2010321204B2|2009-11-23|2014-11-20|Blackberry Limited|Method and apparatus for state/mode transitioning|

---

MX2012005874A|2009-11-24|2012-11-30|Research In Motion Ltd|Method and apparatus for state/mode transitioning.|

---

EP2341687B1|2009-12-30|2016-03-23|BlackBerry Limited|Method and system for allowing varied functionality based on multiple transmissions|

---

US8983532B2|2009-12-30|2015-03-17|Blackberry Limited|Method and system for a wireless communication device to adopt varied functionalities based on different communication systems by specific protocol messages|

---

CN102783241A|2010-02-10|2012-11-14|捷讯研究有限公司|Method and apparatus for state/mode transitioning|

---

US8594747B2|2011-05-06|2013-11-26|Apple Inc.|Adaptive fast dormancy in a mobile device|

---

EP2777358B1|2011-11-11|2018-01-10|BlackBerry Limited|Method and apparatus for user equipment state transition|EP2247146B1|2005-12-14|2011-11-16|Research In Motion Limited|Method and apparatus for user equipment directed radio resource control in a UMTS network|

---

ES2353609T3|2006-05-17|2011-03-03|Research In Motion Limited|METHOD AND SYSTEM FOR INDICATION OF SIGNALING CONNECTION RELEASE IN A UMTS NETWORK.|

---

US20080049662A1|2006-08-25|2008-02-28|Research In Motion Limited|Apparatus, and associated method, for releasing a data-service radio resource allocated to a data-service-capable mobile node|

---

EP2387283B1|2007-11-13|2018-11-28|BlackBerry Limited|Method and apparatus for state/mode transitioning|

---

EP2356878B1|2008-11-10|2015-07-29|BlackBerry Limited|Method and apparatus of transition to a battery efficient state or configuration by indicating end of data transmission in long term evolution|

---

ES2805149T3|2009-11-23|2021-02-10|Blackberry Ltd|State or mode transition trigger based on the transmission of a connection release signaling indication message|

---

AU2010321204B2|2009-11-23|2014-11-20|Blackberry Limited|Method and apparatus for state/mode transitioning|

---

AU2010320843B2|2009-11-23|2014-07-10|Blackberry Limited|Method and apparatus for state/mode transitioning|

---

MX2012005874A|2009-11-24|2012-11-30|Research In Motion Ltd|Method and apparatus for state/mode transitioning.|

---

US20110150262A1|2009-12-22|2011-06-23|HaaLee Inc.|Headset|

---

US8983532B2|2009-12-30|2015-03-17|Blackberry Limited|Method and system for a wireless communication device to adopt varied functionalities based on different communication systems by specific protocol messages|

---

CN106788903A|2010-01-15|2017-05-31|中兴通讯股份有限公司|A kind of transmission UE supports the method and system of multi-carrier capability|

---

US8780744B2|2010-01-25|2014-07-15|Qualcomm Incorporated|Selective allocation of dedicated channelresources within a wireless communications system|

---

KR101674221B1|2010-01-28|2016-11-09|엘지전자 주식회사|Apparatus and method of reporting logged measurement in wireless communication system|

---

US8848553B2|2010-02-05|2014-09-30|Qualcomm Incorporated|Assisted state transitions of a user equipment within a wireless communications system|

---

US20110194433A1|2010-02-05|2011-08-11|Qualcomm Incorporated|Managing dedicated channel resource allocation to user equipment based on radio bearer traffic within a wireless communications system|

---

US8873479B2|2010-02-05|2014-10-28|Qualcomm Incorporated|Assisted state transition of a user equipmentfor delay sensitive applications within a wireless communications system|

---

CN102783241A|2010-02-10|2012-11-14|捷讯研究有限公司|Method and apparatus for state/mode transitioning|

---

KR101661161B1|2010-04-07|2016-10-10|삼성전자주식회사|Apparatus and method for filtering ip packet in mobile communication terminal|

---

US8744534B2|2010-04-30|2014-06-03|Apple Inc.|Methods and apparatus for preserving battery resources in a mobile communication device|

---

JP5147898B2|2010-06-10|2013-02-20|株式会社エヌ・ティ・ティ・ドコモ|Radio control apparatus and communication control method|

---

JP5620578B2|2010-07-26|2014-11-05|セブン ネットワークス インコーポレイテッド|Mobile network traffic regulation across multiple applications|

---

WO2012034580A1|2010-09-13|2012-03-22|Nokia Siemens Networks Oy|Reduced radio resource control connectivity|

---

US8428080B2|2010-09-16|2013-04-23|Apple Inc.|Method to control reconfiguration of multiple radio access bearers in a wireless device|

---

CA2798523C|2010-11-22|2015-02-24|Seven Networks, Inc.|Aligning data transfer to optimize connections established for transmission over a wireless network|

---

CN102149085B|2011-04-21|2014-01-15|惠州Tcl移动通信有限公司|Mobile terminal and multi-access point management method|

---

CN102761952B|2011-04-28|2014-12-24|华为技术有限公司|Method, equipment and system for synchronizing states of physical layers|

---

US9615321B2|2011-06-21|2017-04-04|Qualcomm Incorporated|Apparatus and methods for facilitating cell reselection for higher priority layers|

---

US9007972B2|2011-07-01|2015-04-14|Intel Corporation|Communication state transitioning control|

---

CN102917463B|2011-08-02|2015-04-08|华为技术有限公司|Method, base station and user equipment for transmitting dispatching information|

---

KR20130018036A|2011-08-12|2013-02-20|삼성전자주식회사|Device and method for selecting a cell according mobility of mobile terminal in moblil communication system|

---

US20130100820A1|2011-10-19|2013-04-25|Qualcomm Incororated|Maintaining a user equipment in a shared channel state in a wireless communications system|

---

US20130107727A1|2011-10-27|2013-05-02|Nokia Corporation|Apparatus and Method for the Management of Reception Parameters in a Communication System|

---

EP2777358B1|2011-11-11|2018-01-10|BlackBerry Limited|Method and apparatus for user equipment state transition|

---

US9913163B2|2011-11-16|2018-03-06|Telefonaktiebolaget Lm Ericsson |UE control of downlink data|

---

US20130195049A1|2012-01-29|2013-08-01|Yang Yang|Radio Resource Control Connection Release For User Devices Out Of Up Link Time Alignment|

---

JP6067978B2|2012-03-14|2017-01-25|株式会社Ｎｔｔドコモ|Mobile station and radio base station|

---

JP5865740B2|2012-03-14|2016-02-17|株式会社Ｎｔｔドコモ|Mobile station|

---

US9526091B2|2012-03-16|2016-12-20|Intel Corporation|Method and apparatus for coordination of self-optimization functions in a wireless network|

---

US8837366B2|2012-03-19|2014-09-16|Apple Inc.|Method to use network measurements to optimize mobile wireless device performance|

---

GB2501931A|2012-05-11|2013-11-13|Renesas Mobile Corp|Wireless devices and apparatus and computer programs therefor|

---

JP5668022B2|2012-05-30|2015-02-12|株式会社Ｎｔｔドコモ|State transition timer setting system, mobile device, mobile communication system, and state transition timer setting method|

---

US8611213B1|2012-06-01|2013-12-17|At&T Intelletual Property I, L.P.|Transmitting delay-tolerant data with other network traffic|

---

TWI505737B|2012-06-09|2015-10-21|Apple Inc|Adjusting connection states of a mobile wireless device|

---

WO2014022962A1|2012-08-06|2014-02-13|华为技术有限公司|Signalling sending method and related device|

---

US9781676B2|2012-10-24|2017-10-03|Blackberry Limited|System and method for reducing power consumption based on data activity sensitive timers|

---

US9420616B2|2012-10-29|2016-08-16|Qualcomm Incorporated|Methods to enhance videotelephony to achieve local QoS|

---

US9814025B2|2012-11-29|2017-11-07|Lg Electronics Inc.|Method of reporting information on UE state performed by UE in wireless communication system and device for supporting said method|

---

US20150382298A1|2013-02-15|2015-12-31|Telefonaktiebolaget L M Ericsson |Method and network node for setting a mobile communication terminal in an idle mode|

---

WO2014161151A1|2013-04-02|2014-10-09|Qualcomm Incorporated|Method and apparatus for avoiding call drops during serving radio network subsystemrelocation procedure|

---

US9237564B2|2013-04-17|2016-01-12|Qualcomm Incorporated|Enhanced reconfiguration procedure at a mobile terminal to reduce signaling and power consumption overhead|

---

WO2014200631A1|2013-06-11|2014-12-18|Seven Networks, Inc.|Optimizing keepalive and other background traffic in a wireless network|

---

US10779202B2|2013-07-02|2020-09-15|Telefonaktiebolaget L M Ericsson |Controlling connection of an idle mode user equipment to a radio access network node|

---

US9065765B2|2013-07-22|2015-06-23|Seven Networks, Inc.|Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network|

---

US20160286605A1|2013-11-19|2016-09-29|Telefonaktiebolaget Lm Ericsson |Methods and Means for Radio Bearer Release|

---

US20150201411A1|2014-01-10|2015-07-16|Qualcomm Incorporated|Handling invalid configurations for enhanced uplink in cell_fach state|

---

WO2015172749A1|2014-05-16|2015-11-19|Mediatek Singapore Pte. Ltd.|Enhanced mechanism to access the network for mobile terminal|

---

EP3179765B1|2014-09-03|2019-05-15|Huawei Technologies Co. Ltd.|Characteristic configuration apparatus and method|

---

US10779161B2|2014-09-15|2020-09-15|Nokia Solutions And Networks Oy|Delivery of cellular network insights to subscriber devices through SSID via cellular system information block|

---

WO2016064048A1|2014-10-21|2016-04-28|Lg Electronics Inc.|Method for monitoring downlink control channel in wireless communication system and apparatus for the same|

---

US10939373B2|2014-11-07|2021-03-02|Telefonaktiebolaget Lm Ericsson |Method for enhanced power saving mode for a wireless device|

---

US9967838B2|2014-11-21|2018-05-08|Apple Inc.|Network synchronization for system configuration exchanges|

---

US10453325B2|2015-06-01|2019-10-22|Apple Inc.|Creation of reminders using activity state of an application|

---

US9603123B1|2015-06-04|2017-03-21|Apple Inc.|Sending smart alerts on a device at opportune moments using sensors|

---

US10235863B2|2015-06-05|2019-03-19|Apple Inc.|Smart location-based reminders|

---

US20170142777A1|2015-11-13|2017-05-18|Alcatel-Lucent Usa Inc.|Modifying inactivity timers for user equipment in a wireless communication system|

---

US20170156158A1|2015-11-30|2017-06-01|Nokia Solutions And Networks Oy|Method and apparatus for utilizing communication configuration preferences|

---

US20180213576A1|2017-01-24|2018-07-26|Nokia Technologies Oy|Connection Release Assistance Information|

---

US11178713B2|2017-04-27|2021-11-16|Sony Corporation|Mobile communications network, infrastructure equipment, communications device and methods|

---

EP3637683A4|2017-05-09|2020-05-06|Huawei Technologies Co., Ltd.|Session management method, terminal, and system|

---

US10805978B2|2017-10-25|2020-10-13|Arm Ltd|System, method and device for early connection release of user equipment from communications network|

---

CN109756449B|2017-11-02|2020-10-20|维沃移动通信有限公司|Transmission method of system information block, base station and user terminal|

---

US11096040B2|2019-10-04|2021-08-17|At&T Intellectual Property I, L.P.|Facilitation of multiple subscriber identity module coordination for 5G or other next generation network|

---

US11096144B2|2019-10-04|2021-08-17|At&T Intellectual Property I, L.P.|Paging an idle subscriber identity module using a connected subscriber identity module operating in a single radio configuration for 5G or other next generation wireless network|

---

US11212022B2|2019-10-04|2021-12-28|At&T Intellectual Property I, L.P.|Radio sharing for multiple wireless subscriber identities|

---

US11229012B2|2019-11-18|2022-01-18|Verzon Patent and Licensing Inc.|Dynamic modification of device band and radio access technology information|

法律状态:
2020-11-10| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-11-10| B15K| Others concerning applications: alteration of classification|Free format text: A CLASSIFICACAO ANTERIOR ERA: H04W 76/04 Ipc: H04W 52/02 (2009.01), H04W 76/27 (2018.01), H04W 7 |

---

2020-11-24| B25F| Entry of change of name and/or headquarter and transfer of application, patent and certif. of addition of invention: change of name on requirement|Owner name: RESEARCH IN MOTION LIMITED (CA) Free format text: A FIM DE ATENDER A ALTERACAO DE NOME E DE SEDE REQUERIDAS ATRAVES DA PETICAO NO 860140176194, DE 21/10/2014, E NECESSARIO APRESENTAR A TRADUCAO JURAMENTADA DO DOCUMENTO, ALEM DA GUIA DE CUMPRIMENTO DE EXIGENCIA. |

---

2021-02-09| B25D| Requested change of name of applicant approved|Owner name: BLACKBERRY LIMITED (CA) |

---

2021-03-02| B25G| Requested change of headquarter approved|Owner name: BLACKBERRY LIMITED (CA) |

---

2021-03-30| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-05-18| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 05/10/2010, OBSERVADAS AS CONDICOES LEGAIS. PATENTE CONCEDIDA CONFORME ADI 5.529/DF |

优先权:

---

申请号 | 申请日 | 专利标题

---

US26382309P| true| 2009-11-23|2009-11-23|

---

US61/263,823|2009-11-23|

---

PCT/EP2010/064859|WO2011060997A1|2009-11-23|2010-10-05|Method and apparatus for state/mode transitioning|

---